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(57) Abstract 



A mobile communication system (101) having a layered architecture (401) communicates user and signaling data (1105) among 
components of the communication system in the form of information clemenis which are encapsulated within packets (1005) which may be 
passed across one or more system interfaces (1401). The mobile communication system comprises mobile user stations (102), base stations 
(104), and base station controllers (105) and operates as a transparent data pipeline t>ctween application end users, such as a telephone 
service (126). connected at base station concroUers (105) and mobile user stations (102). In a particular embodiment, the interface between 
the base station (104) and the user stations (102) is a TDM A interface, and signaling traffic between the base station (104) and each of 
the user stations (102) is conducted in either a fast control traffic mode or a slow control traffic mode. In the fast control traffic mode, 
signaling messages arc exchanged between the base station (104) and a user station (102) in a plurality of time slots (302) within a timespan 
of a single time frame (301); in the slow control traffic mode, signaling messages arc exchanged between the base station (104) and a user 
station (102) in no more than a single time slot (302) within a timespan of a single lime frame (301). 
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SPECIFICATION 



TITLE OF THE INVENTION 
Communication System And Method 
Related Applic ^^tion Data 

This application is a continuation-in-part application 
of copending U.S. Application Serial No. 08/532,466 filed on 
5 September 22, 1995 and hereby incorporated by reference as if 
fully set forth herein, which is a continuation-in-part 
application of copending U.S. Application Serial No. 08/284,053 
filed on August 1, 1994, which is a continuation-in-part of U.S. 
Application Serial No. 08/215,306 filed on March 21, 1994, now 
10 abandoned, which is a continuation-in-part of U.S. Application 
Serial No. 08/146,496 filed on November 1, 1993, now abandoned. 

BACKGROUND OF THE INVENTION 



15 1) Field of the Invention 

The field of this invention pertains to communications 
and, more particularly, to means for transferring information 
within a mobile communication system. 



20 2) Description of the Related Art 

Digital communication systems have become increasingly 
popular for many applications. One advantage of a digital 
communication system is the flexibility to carry many different 
types of information over a single system. A single digital 

25 communication system may be used, for example, to transmit 

digitized sound, text, computer data, digital video, or other 
information existing in digital form. 

To achieve flexibility, a communication system may be 
designed to transfer digital information from one end user to 

30 another in a transparent fashion. The communication system then 
operates as a transparent data pipeline for one or more other 
systems which are called application end users. Each 
application end user connected to the communication system 
generally has the responsibility for ensuring that the data 

35 ultimately delivered is in a form which is properly recognized 
by the user. 
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To better achieve such flexibility, it has been 
suggested that a communication system be designed with a layered 
architecture. One example of a general layered architecture for 
digital communication systems is the International Organization 
5 for Standardization (ISO) Reference Model for Open Systems 
Interconnection ("OSI Reference Model"). The OSI Reference 
Model has been adopted as an international standard by the ISO 
and by the International Telephone and Telegraph Consultative 
Committee (CCITT) . 

10 Figure 4A is a diagram showing the OSI Reference Model 

401. The OSI Reference Model 401 comprises a communication 
system having seven layers which form a communication path 
between a first end user 405 and a second end user 410. The 
seven layers may be divided into two sets- -a set of upper layers 

15 415 and a set of lower layers 420. The upper four layers 415 

normally reside in the application end users desiring to 
communicate. A communication system may in some cases be 
defined by the lower three layers 420, individually known as the 
network layer 422, the data link layer 424 and the physical 

2 0 layer 426 . 

In the OSI Reference Model, each layer is responsible 
for specific, defined operations in the communication process 
between application end users 405, 410. In furtherance of these 
operations, each layer may communicate information with the 
25 layers above and below it through defined interfaces (although 
there is not always a definitive separation between layers) . 
Thus, for example, the transport layer may operate independently 
of the specific operational details of the network layer 422, 
the data link layer 424, and the physical layer 426 below it. 
30 The set of lower layers 420 thus operates as a transparent data 
pipeline to an application end user connected to the system at 
the transport layer interface. 

Figure 4B illustrates a flow of data between layers 
such as may occur during communication between two application 
35 end users. As shown in Fig. 4B, information may be passed 

between like layers (e.g., the transport layer in the Fig. 4B 
example) of each end user through a path ultimately connected at 
the physical layer 426. The rules that govern how data is 
passed between like layers at each end user are collectively 
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referred to as a "peer-to-peer protocol." A variety of 
different application end users operating with different peer- 
to-peer protocols may comniunicate over a communication system so 
long as each application end user presents the proper upper 
S layer interface to the communication system. Conversely, an 

application end user may connect with any communication system 
having a compatible lower layer interface. 

Additional details regarding the OSI Reference Model 
may be found in "Telecommunication Networks" by Mischa Schwartz 

10 (Addison-Wesley Publishing Co., 1987). 

One class of digital communication systems provides 
wireless data communication connections to stationary or mobile 
user stations (e.g., handsets) . Examples of such wireless 
mobile communication systems include public safety radio 

15 systems, cellular telephone systems, and personal communication 
systems (PCS) . A wireless communication system may include a 
number of base stations for completing communication paths with 
the user stations. The base stations may be connected to a 
network, either directly of via a switch. 

20 In many mobile communication systems it is desired 

that user stations have the ability to initiate and receive 
telephone calls. By connecting a communication system to a 
public switched telephone network (PSTN) , a user station may 
generally communicate with any telephone connected to the 

25 telephone network. Alternatively, a communication system may 
access the telephone system through an intermediate 
communication system such as the Global System for Mobile 
Communications (GSM) , 

In operation, it is often necessary to pass signaling 

30 information among various components of a communication system. 
Signaling information may, for example, comprise control 
messages relating to the operation of the communication system. 
An example of signaling information is a message from a user 
station to a base station indicating a malfunction. One 

35 difficulty with the user of signaling information is that it 

must be distinguished within the system from data communication 
(i.e., information intended solely for the application end 
user) , and must be extracted by the system component needing the 
signaling information to perform its tasks. 



5NS0OCID: <WO 9713353A1_(.> 



wo 97/13353 PCT/US96/15190 

4 

The transfer of necessary control and data information 
can be difficult within certain types of wireless systems. For 
example, in a time division multiple access (TDMA) system, 
wherein a base station communicates with a plurality of user 
stations (typically mobile) in a different time slots, the 
amount of information that can be transferred between the base 
station and the user station in a given time slot is necessarily 
limited. In contrast, a network to which a call is connected 
often transfers information in large data blocks (e.g., 64 
kilobyte segments) . The base station should have the capability 
of supporting data transfers and control functions required by 
the network, while at the same time supporting the transfer of 
information and control messages to the user station over a TDMA 
channel . 

15 It would be advantageous to provide a mobile 

communication system with an improved method of communicating 
both user and signaling data among system components. 
It would be further advantageous to provide a mobile 
communication system having the characteristics of a layered 
architecture so as to provide a transparent data pipeline to 
application end users. 



10 



20 



SUMMARY OF THE INVENTION 
The present invention comprises in one aspect a system 

2 5 and method of transferring information (including user data and 

signaling information) within a mobile communication system. 

In one aspect of the invention, internal components of 
a mobile communication system communicate system signaling data 
across internal interfaces implemented according to a layered 
30 architecture. System interfaces effectively function as 

communication channels between the system components. The 
system components appear as application end users to the 
internal communication channels defined by the system 
interfaces . 

3 5 In another aspect of the invention, a mobile 

communication system transfers signaling data and end user data 
over a common set of interfaces, without using separate or 
dedicated internal communication channels for signaling data. 
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In a preferred embodiment, the communication system 
includes a base station capable of communicating with a 
plurality of user stations. The base station is connected with 
a base station controller (which may also be connected to other 
5 base stations) . The base station controller may be connected to 
a network. In a preferred embodiment, the base station 
comprises two separate processors, an over- the -air (OTA) 
processor and a base station controller (BSC) interface 
processor (also called a line card processor) . The OTA 

10 processor controls a base station transceiver which carries out 
communication with user stations over communication links. In a 
preferred embodiment, the interface between the OTA processor 
and the line card processor comprises a dual-port RAM which is 
used as a shared resource across the interface. Prioritized 

15 queues may be used to facilitate response to relatively higher 
priority signaling and control messages. 

In another aspect of the invention, an over-the-air 
interface provides for the transfer of signaling information or 
data information, or both. The over-the-air interface comprises 

20 a plurality of time division multiple access (TDMA) channels. 
An information packet sent over a TDMA channel includes a 
relatively long bearer field (B-field) and a relatively short 
byte-serial field (also called a D-field) . Low priority 
signaling messages may be segmented and transmitted over a 

25 plurality of time slots in the D-field. Higher priority 

signaling messages may be sent in the B-field, pre-empting 
normal bearer traffic. A field or flag in a header of an OTA 
information packet indicates to the receiving entity the usage 
of the B-field and the D-field for a given packet. 

30 In a particular embodiment of the invention where the 

interface between the base station and the user stations is a 
TDMA interface, signaling traffic between the base station and 
each of the user stations is conducted in either a fast control 
traffic mode or a slow control traffic mode. In the fast 

35 control traffic mode, signaling messages are exchanged between 

the base station and a user station in a plurality of time slots 
within a timespan of a single time frame; in the slow control 
traffic mode, signaling messages are exchanged between the base 
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station and a user station in no more than a single time slot 
within a timespan of a single time frame. 

The above aspects of the invention are described with 
respect to preferred sets of messages, wherein each set of 
messages is associated with a different interface between system 
components . 

BRIEF DESCRIPTION OF THE DRAWINGS 

The various objects, features and advantages of the 
present invention may be better understood by examining the 
Detailed Description of the Preferred Embodiments found below, 
together with the appended figures, wherein: 

Fig. lA is a diagram of a pattern of cells in a 
wireless communication system. 

Fig. IB is a block diagram of a communication system. 

Fig. IC is a diagram of an arrangement of cells in a 
wireless communication system showing an exemplary code and 
frequency reuse pattern. 

Fig. 2 is a block diagram of a transmitter and a 
receiver in a spread spectrum communication system. 

Fig, 3 is a diagram of a time frame divided into a 
plurality of time slots. 

Fig. 4A is a diagram of a multi- layer communication 
system architecture according to the OSI Reference Model. 

Fig. 4B is a diagram illustrating peer-to-peer 
communication in the layered communication system architecture 
of Fig. 4A. 

Fig. 5A is a diagram of a preferred slot structure, 
and Figs. 5B and 5C are diagrams of a base station traffic 
message structure and a user station traffic message structure, 
respectively . 

Fig. 6 is an abstract diagram illustrating the 
transfer of information {including internal signaling messages) 
among system components in a preferred wireless communication 
system. 

Fig. 7 is an abstract diagram illustrating the 
transfer of information to and from a particular network in 
accordance with the system components and interfaces of Fig. 6. 
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Fig. 8 is a diagram of an embodiment of the Fig. 6 
system architecture focusing on the base station interfaces. 

Fig. 9 is a diagram illustrating a breakdown of 
software functionality within a base station. 
5 Fig. 10 is a diagram of an information packet in 

accordance with one embodiment of the present invention. 

Fig. 11 is a diagram of an exemplary data frame for 
transmitting messages to and from a base station controller. 

Fig. 12 is a diagram of an exemplary address field in 
10 the data packet of Fig. 11. 

Fig. 13 is a diagram of a process for communicating 
signaling data among system components in a preferred mobile 
communication system . 

Fig. 14 is a diagram of a particular I-interface 
15 architecture utilizing a shared memory element (i.e., dual -port 
RAM), and Fig. 15 is a table of an exemplary dual-port RAM map. 

Figs. 16A and 16B are a block diagrams of a base 
station showing separate controllers and interface components. 

Figs. 17A and 17B are exemplary dual-port RAM maps. 

20 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 
Figure lA is a diagram of a pattern of cells in a 
wireless communication system 101 for communication among a 
plurality of user stations 102. The wireless communication 

25 system 101 of Fig. lA includes a plurality of cells 103, each 

with a base station 104, typically located at the center of the 
cell 103. Each station (both the base stations 104 and the user 
stations 102) generally comprises a receiver and a transmitter. 

In a preferred embodiment, a control station 105 (also 

30 comprising a receiver and a transmitter) manages the resources 
of the system 101. The control station 105 (sometimes referred 
herein as a "base station controller") may assign the base 
station 104 transmitters and user station 102 transmitters in 
each cell 103 a spread -spectrum code for modulating radio signal 

35 communication in that cell 103. The resulting signal is 

generally spread across a bandwidth exceeding the bandwidth 
necessary to transmit the data, hence the term "spread 
spectrum". Accordingly, radio signals used in that cell 103 are 
spread across a bandwidth sufficiently wide that both base 
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station 104 receivers and user station 102 receivers in an 
adjacent cell 103 may distinguish communication which originates 
in the first cell 103 from communication which originates in the 
adjacent cell 106. 
5 Figure IB is a block diagram of a communication system 

architecture utilized in a preferred embodiment of the present 
invention. The Fig. IB communication system comprises a 
plurality of base stations 104 for communicating with a 
plurality of user stations 102. The base stations 104 and user 
10 stations 102 may operate in a personal communications system 

(PCS) , such as may be authorized under rules prescribed by the 
Federal Communications Commission (FCC) . 

Each base station 104 may be coupled to a base station 
controller 105 by any of a variety of communication paths 109. 
15 The communication paths 109 may each comprise one or more 
communication links 118. Each communication link 118 may 
include a coaxial cable, a fiber optic cable, a digital radio 
link, or a telephone line. 

Each base station controller 105 may also be connected 
20 to one or more communication networks 126, such as a public 
switched telephone network (PSTN) or personal communication 
system switching center (PCSC) . Each base station controller 
105 is connected to a communication network 126 by means of one 
or more communication paths 108, each of which may include a 
25 coaxial cable, a fiber optic cable, a digital, radio link, or a 
telephone line. 

The Fig. IB communication system also may include one 
or more "intelligent" base stations 107 which connect directly 
to a communication network 126 without interfacing through a 
30 base station controller 105. The intelligent base stations 107 
may therefore bypass the base station controllers 105 for local 
handoffs and switching of user stations 102, and instead perform 
these functions directly over the network 126 . In terms of the 
interfaces described hereinafter (see Fig. 6) , an intelligent 
35 base station 107 does not require an N- Interface, and the 

functions of the base station controller 105 for transmitting to 
the network 126 are incorporated within the intelligent base 
station 107. 
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In operation each base stations 104 formats and sends 
digital information to its respective base station controller 
105 (or directly to the network 126 in the case of an 
intelligent base station 107) . The base station controllers 105 
5 receive inputs from multiple base stations 104, assist handoffs 
between base stations 104, and convert and format channel 
information and signaling information for delivery to the 
network 126. The base station controllers 105 may also manage a 
local cache VLR database, and may support basic operation, 

10 administration and management functions such as billing, 

monitoring and testing. Each base station controller 105, under 
control of the network 126, may manage local registration and 
verification of its associated base station 104 and may provide 
updates to the network 126 regarding the status of the base 

15 stations 104. 

The network 126 connects to the base station 
controllers 105 for call delivery and outgoing calls. 
Intelligent base stations 107 may use ISDN messaging for 
registration, call delivery and handoff over a public telephone 

20 switch. The intelligent base station 107 may have all the 
general capabilities of a base station 104 but further 
incorporate a BRI card, additional intelligence and local 
vocoding . 

If the network 126 is a GSM network, then base 
25 stations 104 may connect to the network 126 through a defined 
"A" interface. The "A" interface may be incorporated in base 
station controllers 105 and in intelligent base stations 107 . 
Features and functionality of GSM may be passed to and from the 
base stations 104 over the "A" interface in a manner that is 
30 transparent to the end user. 

The system may also interconnect to cable television 
distribution networks. The base stations 104 may be 
miniaturized so that they can be installed inside standard cable 
TV amplifier boxes. Interfacing may be carried out using analog 
35 remote antenna systems and digital transport mechanisms. For 
example, Tl and FTl digital multiplexer outputs from the cable 
TV network may be used for interfacing, and basic rate (BRI) 
ISDN links may be used to transport digital channels. 
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Figure IC is a diagram of a particular cellular 
environment in which the invention may operate. In Fig. IC, a 
geographical region 132 is divided into a plurality of cells 
130. Associated with each cell 130 is an assigned frequency 
5 from among frequencies Fl, F2 and F3 , and an assigned spread 
spectrum code (or code group) from among the codes (or code 
groups) CI, C2 , C3 , C4 , C5 and C6 . The three different 
frequencies Fl, F2 and F3 are preferably assigned in such a 
manner that no two adjacent cells 130 have the same assigned 
10 frequency Fl, F2 or F3 , thereby resulting in minimization of 
interference between adjacent cells 130, The spread spectrum 
codes CI through C6 are preferably orthogonal and may be 
assigned in adjacent clusters 131 such as shown in Fig. IC. 
Although six spread spectrum codes CI through C6 are depicted in 
15 Fig. IC, other numbers of spread spectrum codes may be used 
depending upon the particular application. 

Further details regarding an exemplary cellular 
pattern are described in, e.g., U.S. Patent No. 5,402,413, 
entitled "Three Cell Wireless Communication System, " which 
20 application is assigned to the assignee of the present 

invention, and is hereby incorporated by reference as if fully 
set forth herein. 

Figure 2 is a block diagram of an exemplary 
transmitter and receiver in a spread spectrum communication 
25 system as may be employed for spreading and bespreading signals 
in the communication system of Fig. lA. In Fig. 2, a spread- 
spectrum transmitter 201 comprises an input port 202 for input 
data 203, a chip sequence transmitter generator 204, a modulator 
2 05 , and a transmitting antenna 2 06 for transmitting a spread - 
30 spectrum signal 207. A spread- spectrum receiver 208 comprises a 
receiver antenna 209, a chip sequence receiver generator 210, a 
demodulator 211, and an output port 212 for output data 213. In 
operation, a single chip sequence 214 is identically generated 
by both the transmitter generator 2 04 and the receiver generator 
35 210, and appears essentially random to others not knowing the 
spreading code upon which it is based. The spread- spectrum 
signal 207 is despread with demodulator 211 by correlating the 
received signal with a locally generated version of the chip 
sequence 214. Exemplary correlators are described in, e.g., 
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U.S. Patent Nos , 5,022,047 and 5,016,255, each of which are 
assigned to the assignee of the present invention, and each of 
which are incorporated by reference as if fully set forth 
herein. A preferred method of correlation is described in U.S. 
5 Patent Application Serial No. 08/481,613 entitled "Multi-Bit 

Correlation of Continuous Phase Modulated Signals," filed June 
7, 1995, hereby incorporated by reference as if set forth fully 
herein . 

Spread spectrum communication techniques are further 

10 described in, e.g., Robert C. Dixon, Spread Spectrum Systems 

with Commercial Applications (John Wiley & Sons, 3d ed. 1994) . 

Data may be transmitted between the base station 104 
and user stations 102 using an M-ary spread spectrum technique. 
Suitable M-ary spread spectrum transmission and reception 

15 techniques are described in, e.g., U.S. Patent No. 5,022,047 and 

in U.S. Patent Application Serial No. 08/484,007 entitled 
"Method and Apparatus for Decoding a Phase Encoded Signal," 
filed June 7, both of which are incorporated by reference as if 
set forth fully herein. In a preferred embodiment, the base 

20 station 104 and user stations 102 each transmit an M-ary direct 
sequence spread spectrum signal, with M=6 , using spread spectrum 
codes {called "symbol codes") of 32 chips. Thirty- two different 
symbol codes are used to represent up to thirty-two different 
data symbols, each comprising five bits of data; phase encoding 

25 may also be used to allow transmission of a 6^th bit of data for 
each symbol code. Techniques of phase encoding for transmission 
of an additional bit of information per symbol code are 
described in, e.g., U.S. Patent Application Serial No. 
08/484,007, referenced above. 

30 User stations 102 in one embodiment may comprise 

mobile handsets capable of multi-band and/or multi-mode 
operation. The user, stations 102 may be mult i -mode in that they 
may be capable of both spread spectrum (i.e., wideband) 
communication and also narrowband communication. The user 

35 stations 102 may be multi-band in the sense that they may be set 
to operate on a plurality of different frequencies, such as 
frequencies in either the licensed or unlicensed PCS bands. The 
user stations 102 may operate in one mode (e.g., wideband) over 
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a first frequency band, and another mode (e.g., narrowband) over 
a second frequency band. 

As an example, a user station 102 may be set to 
operate on a plurality of frequencies between 1850 and 1990 MHZ, 
with the frequencies separated in 625 kHz steps. Each user 
station 102 may be equipped with a frequency synthesizer that 
may be programmed to allow reception and/or transmission on any 
one of the plurality of frequencies. Further information 
regarding dual-mode and/or dual-band communication is set forth 
in U.S. Patent Application Serial No. 08/483,514 (attorney 
docket 214/071) entitled "Dual-Mode Wireless Unit with Two 
Spread Spectrum Frequency Bands," filed on June 7, 1995 in the 
name of inventors Robert C. Dixon et al . 

Figure 3 is a diagram showing a timing structure for a 
15 particular TDMA system. According to the timing structure of 
Fig. 3, communication over time is broken into a continuous 
series of time frames 301. A single complete time frame 301 is 
shown along a timeline 310 in Fig. 3; similar time frames are 
assumed to precede and follow time frame 301 in a continuous 
20 pattern along the timeline 310. 

Time frame 301 is divided into a plurality of time 
slots 302 numbered consecutively TSl, TS2...TSN, each of which 
may support duplex communication with a user station 102. Time 
frame 301 may be thought of as a "polling loop" or a time loop, 
25 as depicted in Fig, 3, whereby user stations 102 are 

communicated with sequentially over the time frame 301 in a 
manner analogous to polling, each user station 102 transmitting 
and receiving messages in its designated time slot 302. In the 
Fig. 3 embodiment, each time slot 3 02 comprises a user portion 
30 305, wherein a user station 102 transmits a user- to-base message 
to the base station 104, and a base portion 306, wherein the 
base station 104 transmits a base-to-user message to the user 
station 102. 

Time slots 302 define a set of transmission channels. 
35 Each transmission channel may further defined by a distinct 

frequency channel, a distinct spread spectrum code, a distinct 
spatial direction, or some combination thereof. 

In an exemplary TDMA communication system, time frames 
301 are each 20 milliseconds in duration, and each time frame 



NSDOCID: <WO 9713353A1_L> 



wo 97/13353 PCT/US96/15190 

13 

301 comprises sixteen time slots 302 or, alternatively, eight 
time slots 302 to support extended range through increased guard 
times. In a preferred embodiment, each time slot 302 is 1.25 
milliseconds long. Each time slot 302 in such an embodiment 
5 comprises a total of 3125 chip periods, and base station 

transmissions sent during base portions 306 of the time slot 302 
and user station transmissions sent during user portions 305 of 
the time slot 302 each have a chipping rate of 2.5 Megachips/ 
second . 

10 In some embodiments, a user station 102 may 

communicate in more than one time slot 302 in each time frame 
301, so as to support an increased data rate. Similarly, in 
some embodiments, a user station 102 may periodically skip time 
frames 301 and communicate in some subset of all time frames 3 01 

15 (e.g., every other time frame 301, or every fourth time frame 

301) , so as to support a reduced data rate where a full speed 
communication link is not necessary. Further information about 
an exemplary TDMA system supporting variable data rates may be 
found in copending U.S. Patent Application Serial No. 08/284,053 

20 filed August 1, 1994, which is hereby incorporated by reference 

as if fully set forth herein. An alternative over-the-air 
protocol is also described therein. 

Figure 5A is a diagram of a preferred slot structure, 
and Figs. 5B and 5C are diagrams of a base station traffic 

25 message structure and a user station traffic message structure, 
respectively. In Fig. 5A, a time slot 510 comprises a variable 
radio delay gap 505, a user station transmit frame 515, a base 
processor gap 525, a guard time 535, a base station transmit 
frame 54 5, and a radar gap 555. Each user station transmit 

30 frame 515 comprises a user preamble 516, a user preamble 

sounding gap 519, and a user station data frame 521. Similarly, 
each base station transmit frame 54 5 comprises a base preamble 
547, a base preamble sounding gap 54 9, and a base transmit data 
frame 551. 

35 Figure 5B illustrates a preferred message structure 

for the base transmit data frame 551. The message structure of 
Fig. 5B comprises a base header field 553, a base D- channel 
field 557, a base data field 559, and a base cyclical redundancy 
check (CRC) field 561. In a preferred embodiment, the base 
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header field 553 is 23 bits, the base D-channel field 557 is 8 
bits, the base data field 559 is 192 bits, and the base CRC 
field 561 is 16 bits. 

Figure 5C illustrates a preferred message structure 

5 for the user station transmit data frame 521. The message 

structure of Fig. 5C comprises a user header field 523, a user 
D-channel field 527, a user data field 529, and a user CRC field 
531. In a preferred embodiment, the user header field 523 is 17 
bits, the user D-channel field 527 is 8 bits, the user data 

.0 field 529 is 192 bits, and the user CRC field 531 is 16 bits. 

Signaling messages (i.e., messages used for control 
traffic) may be used to assist in acquisition and maintenance of 
a channel from the network. A message may include a message 
type data element located in a message type field. The message 

L5 type data element defines the format of the rest of the message, 
and acts as an operation code to the destination unit (either 
user station 102 or base station 104) . Exemplary message types 
(and their abbreviations) appear in Table 1 below. 

Table 1 
Message 
Acknowledge 

Authentication Request 
Authentication Response 
Base Assist Information 
Base Assist Request 
Set Cipher Mode 
Call Connected 
Connect Link 
Circuit Switch Complete 
De-registration Request 
Hold 

Handover Failed 

User Station Assist Information 
User Station Assist Request 
Originating Handover Complete 



20 

Message Tvpe 
ACK 
AUT 
AUR 

25 BAI 

CIP 
CNC 
CNL 

3 0 CSC 

DRG 
HliD 
HOF 
MAI 

35 MAR 

OHC 
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ORH 


Originating Handover Request 


ORG 


Originate Call 


RCP 


Registration Complete 


REL 


Release Link 


RRQ 


Registration Request 


SPR 


Specific Response 


STL 


Set Link 


SYN 


Synchronize 


THC 


Terminating Handover Complete 


THR 


Target handover Request 


TRA 


Transport Message with TCID 



The message type data element may be, e.g., 8 bits in length. 

Figure 6 is a diagram of various system components 

15 within a preferred wireless communication system showing 

interfaces between the components. Four distinct interfaces are 
defined in the Fig. 6 system, labeled "M" , "O" , "I", and "N" , 
and are referred to herein as the M- Interface 605, O- Interface 
610, I-Interface 615, and N-Interface 620, respectively. 

20 The M-Interface 605 may be internal to a user station 

102 and generally defines a boundary between an application end 
user 602 and a mobile communication transceiver 603 in the user 
station 102. The O-Interface 610 generally comprises 
communication channel (typically an over-the-air communication 

2 5 channel) between the mobile communication transceiver 6 03 in the 
user station 102 and a base station transceiver 604, The I- 
Interface 615 may be thought of as "internal" to a base station 
104 and generally defines a boundary between the base station 
transceiver 604 and a base station line card processor 606. 

30 Finally, the N-Interface 620 comprises an information channel 
607 between the line card processor 606 and a base station 
controller 609 (such as, e.g., base station controller 105 shown 
in Fig. IB) . 

Within the communication system 101, information is 
35 communicated across each interface 605, 610, 615, and 620 
according to a particular protocol governing exchange of 
information across that interface. Thus, a total of four 
protocols are defined, one for each interface 605, 610, 615, 
620. A fifth protocol may be defined for an adaptation layer 
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interface (e.g., the GSM "A" interface) at the base station 

controller 105. 

In a preferred embodiment, the communication system 
101 communicates both user data and signaling data across one or 
5 more of the system component interfaces under the same or 

similar protocols. User data (also referred to as bearer data) 
comprises, in general, data which originates at the application 
end user and is passed to the communication system across an 
adaptation layer interface. User data may include voice, error- 
10 controlled data, or non-error controlled (raw) data. Signaling 
data (also called control data) , on the other hand, generally 
comprises information exchanged within the communication system, 
or between the communication system and application end users, 
for the purpose of service connection (i.e., connection 
15 . establishment and maintenance) . 

The mobile communication system 101 transfers 
information across one or more system interfaces through a 
series of packetized messages referred to as "Notes". Each Note 
may contain data intended for receipt by an application end user 
20 (user data) or data to be used for link establishment and 

maintenance (signaling data), or both. Each interface 605, 610, 
615, 620 communicates with Notes formatted according to a 
particular protocol specific to the interface. 

The mobile communication system 101 transfers 
25 information comprising signaling data and user data between a 

base station 104 (i.e., the base station transceiver 604) and a 
user station 102 (i.e., the mobile station transceiver 603) 
across the O- Interface 610. In a preferred embodiment, the O- 
Interface 610 operates according to an over-the-air protocol 
3 0 with time division duplexing (TDD) and time division multiple 
access (TDMA) techniques. A preferred protocol for the O- 
Interface 610 is shown in and described with respect to Fig. 3. 

Signaling data is passed across the O-Interface 610 in 
the form of messages referred to as "O-Notes" . In a preferred 
35 embodiment, the O-Notes are contained either within the base 
data field 559 (see Fig. 5B) or the user data field 529 (see 
Fig. 5C) , depending upon the origin of the message. 
Alternatively, an O-Note may be segmented into, e.g., 8-bit 
segments and transmitted over a plurality of time slots 302 in 
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the D-field 557 of the base message (see Fig. 5B) or the D-field 
527 of the user message (see Fig. 5C) . Generally, lower 
priority O-Note messages may be segmented and transmitted in the 
D-fields 557 or 527, while higher priority O-Note messages may 
5 be transmitted in the B-fields 579 or 529. Also, O-Notes may be 
transmitted in the B-field 579 or 529 when it is not otherwise 
being used (e.g., when the link is first being established and 
voice data is not being transferred yet) . 

A field or flag in the header of a base message or 
10 user message can be used to indicate whether an O-Note is 

contained in the B-field 579 or 529, or in the D-field 557 or 
527. In some circumstances, an extended O-Note may be sent in a 
message covering both the D-field and the B-field. 

Figure 10 is a diagram of an information packet 1005 
15 (e.g., the base message of Fig. 5B or the user message of Fig. 

5C) which may be passed across the O- Interface 610. An O-Note 
1010 is encapsulated within the packet 1005, and resides in the 
data field 529, 559 ordinarily reserved for bearer traffic. 
Each information packet 1005 generally also comprises a header 
20 1015 of, e.g., 24 bits, a D-field of, e.g., 8 bits, and a frame 

check word 1020 of, e.g., 16 bits, for a total of 240 bits. 

In a preferred embodiment, each O-Note 1010 has a 
length of no more than 160 bits, thereby taking up less space 
than the entire B-field 529 or 569 The latter 32 bits of the O- 
25 Note 1010 (appended to the first 160 bits) may be used for 
forward error correction. 

Table 2-1 through Table 2-33 illustrate exemplary O- 
Notes 1010 which may be transferred across the O-Interface 610 
in a preferred embodiment of the communication system 101. In 
3 0 Table 2-1 through Table 2-33, a mobile communication transceiver 
603 may be denoted "MS-OTA" and a base station transceiver 604 
may be denoted "BS-OTA." 



35 
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Table 2-1 

CT-ACK (Acknowledge) [MS-OTA < = > BS-OTA] 



Information Element 


Length in Bits 


Command Type 


8 


ACK Response 


8 


ACK' ed Command 


8 


Cause 


8 


Reserved 


128 


<TotaJ Bits In MSG> 


160 



Acknowledge messages can be transmitted by either the 
BS-OTA or the mobile communication transceiver 603. They are 
15 usually the last element of a larger signaling exchange. 

Table 2-2 

CT-ASI (Assist Information) [MS-OTA <=> BS-OTA] 



Information Element 


Length in Bits 


Message Type 


8 


Assist Type 


8 


Assist Data 


144 



25 <Total Bits in MSG> 160 



This message is sent either from the BS-OTA to the mobile 
communication transceiver 603 or from the mobile communication 
transceiver 603 to the BS-OTA. It provides a mechanism to impart 
30 various items of information to assist the recipient in making 
well formed decisions. It may be sent in response to a CT-ASR 
message or it may be unsolicited. 



35 
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Table 2-3 

CT-ASR (Assist Request) [MS-OTA <=> BS-OTA] 



Information Element 


Length in Bits 


Message Type 


8 


Assist Type 


8 


Assist Request Info 


144 



< Total Bits In MSG> 16 0 

10 

This message is sent either from the BS-OTA to the 
mobile communication transceiver 603 or from the mobile 
communication transceiver 603 to the BS-OTA to request 
information. It provides a mechanism for the sender to request 
15 various items of information to assist it making well informed 
decisions . 

Table 2-4 

CT-AUR (Authentication Reject) [MS-OTA <=> BS-OTA] 

20 



Information Element 


Length in Bits 


Message Type 


8 


TCID 


8 


Cause 


8 


Reserved 


136 



<Total Bits In MSG> 160 



This message shall be sent to the mobile communication 
30 transceiver 603 from the BS-OTA to inform the mobile 

communication transceiver 603 that the Network Application has 
rejected its Authentication Response. 

35 
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Table 2-5 

CT-AUR (Authentication Response) [MS-OTA < = > BS-OTA] 



Information Element 


Length in Bits 


Message Type 


8 


TCID 


8 


Authentication Test 
Response 


128 


Reserved 


16 



10 

<Tatal Bits In MSG> 16 0 

The authentication response message shall be the 
mobile communication transceiver 6 03 response to an 
15 authentication challenge. It shall contain the results of 

encrypting the test number supplied by the authenticate message 
using the secret unique mobile user station traffic key. 

Table 2-6 

20 CT-AUT (Authentication Challenge) [MS-OTA <= BS-OTA] 



Information Element 


Length in Bits 


Message Type 


8 


TCID 


8 


Cipher Type 


8 


Cipher Key Sequence # 


8 


Authentication Test 
Number 


128 


<Total Bits In MSG> 


160 



This message shall be sent to the mobile communication 
transceiver 603 from the BS-OTA whenever the BS starts an 
authentication sequence. This message shall supply a 128 bit 
35 challenge number to be used by the mobile user station 102 using 
the unique secret mobile user station traffic key to generate 
the authentication response message. 
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Table 2-7 

CT-AUG (Authentication Rejection) [MS-OTA <= BS-OTA] 



Information Element 


Length in Bits 


Message Type 


8 


TCID 


8 


Cause 


8 


Reserved 


136 


<TotAl Bits In MSG> 


160 



This message shall be sent to the mobile communication 
transceiver 603 from the BS-OTA whenever the communication 
system 101 rejects an Authentication Response from the mobile 
15 communication transceiver 603. 



Table 2-8 

CT-CIP (Set Cipher Mode) [MS -OTA <= BS-OTA) 



Information Element 


Length in Bits 


Message Type 


8 


Cipher Algorithm ID 


8 


Frame Number 


24. . 


Frame Offset 


8 


Cause 


8 


Request PID Type 


8 


Reserved 


88 



<Total Bits In MSG> 152 
30 This message is sent to the mobile communication 

transceiver 603 from the BS-OTA whenever the base station 104 
wishes the mobile communication transceiver 603 to switch to 
cipher mode. When the mobile communication transceiver 603 
receives this message the mobile communication transceiver 603 
35 uses the cipher mode parameters to set its ciphering equipment 

and then switches into or out of cipher mode. All traffic after 
this point will be ciphered. 
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Tcible 2-9 CT-CNC 

(Connection Complete) [MS -OTA <= BS-OTA] 



Information Element 


Length in Bits 


Message Type 


8 


TCID 


8 


Connection Number 




OTA Map Type 


8 


OTA Map 


32 


Cipher Algorithm ID 


8 


Frame Number 


24 


Frame Offset 


8 


Reserved 


40 



<Total Bits In MSG> 16 0 



The CT-CNC message is set from the terminating base 
station 104 to the mobile communication transceiver 603 when a 
handover is completed. 

20 

Table 2-10 

CT-CSC (Circuit Switch Complete) [MS-OTA <= BS-OTA] 



Information Element 


Length in Bits 


Message Type 


8 


(New) Zone 


40 


(New) Base ID 


32 


HRef 


48 


Reserved 


32 



30 

<Total Bits In MSG> 160 



This message is set from the source base station 104 
to the mobile communication transceiver 603 to signal that the 
communication system connection is available at the target bas 
station 104 . 
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Table 2-11 

CT-DRG (De-registration) [MS-OTA -> BS-OTA] 



Information Element 


Length in Bits 


Message Type 


8 


Cause 


8 


Reserved 


144 



<Total Bits In MSG> 160 

10 

The mobile communication transceiver 603 shall send a 
de-registration message to the BS-OTA when the mobile 
communication transceiver 603 de-registers itself from the base 
station 104. If the mobile communication transceiver 603 does 
15 not send this message, de-registration shall automatically occur 
a fixed time-out period (e.g., 30 seconds) from the last time 
the mobile communication transceiver 603 sent a registration 
request to the base station 104. 



20 Table 2-12 

CT-HLD (Hold) [MS-OTA < = > BS-OTA] 



Information Element 


Length in Bits 


Message Type 


8 ^ 


OTA Map Type 


8 


OTA Map 


32 


Reserved 


112 


< Total Bits In MSG> 


160 



30 

Table 2-13 
CT-GPO (General Poll) [MS <==> BS] 
The BS broadcasts a CT-GPO when it has channels available. 
The CT-GPO is a general invitation to any MS to attempt to seize 
35 a TDD channel (time slot) . This poll indicates a free channel 
(time slot) . 
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Information Element 


Length in Bits 


Message Type 


8 


Zone 


40 


BSC ID 


16 


Base ID 


32 


BS Capabilities 


32 


System Type 


8 


Service Provider 


16 


Slot Quality 


8 



< Total Bits In MSG> 



ISO 



15 



Table 2-14 

CT-GPR (General Poll Response) [MS <==> BS] 

The MS shall send a CT-GPR message to the BS in response to 
a CT-GPO when the MS wishes to acquire a link to the BS 



20 



25 



30 



Information Element 


Length in Bits 


Message Type 


8 


Transaction Hint 


8 


Transaction Hint 
Qualifier 


8 


PID 


72 . 


Service Provider 


16 


Class 


16 


MS Capabilities 


16 


Reserved 


16 



Total Bits In MSG> 



160 



35 



Hold packets can be transmitted by either the BS-OTA or the 
mobile communication transceiver 603. They are always part of a 
larger signaling traffic exchange and are used to maintain the 
communication link across the O- Interface 610 while waiting for 
an external event . 
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Table 2-15 
CT-HOF (Handover Failure) [MS <==> BS] 
This message is sent to the MS by either the Originating BS or 
the Terminating BS to indicate to the MS that the requested 
5 handover (OHR or THR) has failed. 



Information Element 


Length in Bits 


Message Type 


8 


Cause 


8 


Reserved 


144 



<Total Bits In MSG> 16 0 



Tcible 2-16 

15 CT-IRP (Identity Reply) [MS-OTA => BS-OTA] 



Information Element 


Length in Bits 


Message Type 


8 


Identity Type 


8 


Identity Data 


72 


Message Sequence 
Number 


8 


Reserved 


64 


< Total Bits In MSG> 


160 



The mobile communication transceiver 603 sends a CT- 
IRP message to the BS-OTA in response to a CT-IRQ message, 

30 



35 
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Table 2-17 

CT-IRQ (Identity Request) [MS-OTA <= BS-OTA] 



10 



15 



Information Element 


Length in Bits 


Message Type 


8 


Identity Type 


8 


Reserved 


144 



<Total Bits In MSG> 



160 



The BS-OTA sends a CT-IRQ message to the mobile 
communication transceiver 603 when it receives an Identity 
Request Note from an application end user connected to a base 
station controller 105. This allows the application end user to 
obtain one of the mobile user station's Identifiers that is not 
normally included in the protocol. 



Table 2-18 
CT-OHC (Originating Handover Complete) 
[MS-OTA => Target BS-OTAl 



25 



Information Element 


Length in Bits 


Message Type 


8 


HRef 


8 


PID 


72 


Registration Type 


8 


Registration Status 


8 


Reserved 


16 



<Total Bits In MSG> 16 0 



The Originating Handover Complete message is sent f 
the mobile communication transceiver 603 to the target (new) 
base station to complete the Originating Handover procedure. 

35 
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Table 2-19 
CT-OHR (Originating Handover Request) 
[MS-OTA => Originating BS-OTA] 



Information Element 


Length in Bits 


Message Type 


8 


(New) Zone 


40 


(New) BSC ID 


16 


(New) Base ID 


8 


Remaining Base 
Count 


8 


Reserved 


56 


<Tot^l Bits In MSG> 


160 



Originating Handovers will be attempted in cases when 
supporting a system such as DCS1900, where a terminating 
handover is not possible because there is no way the new base 
station controller 105 can notify the old base station 
20 controller 105 that the handover is required. The Originating 
Handover Request message is sent from the mobile communication 
transceiver 603 to the source BS-OTA to initiate the originating 
handover procedure . 

25 Table 2-20 

CT-PPR (Paging Poll Response) [MS-OTA <==> BS-OTA] 
The MS send the CT-PPR message to the BS in response to a 
CT-PPRO from the BS . 



35 
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Information Element 


Length in Bits 


Message Type 


8 


PID 


72 


Service Provider 


16 


Class 


16 


MS Capabi 1 i t i e s 


16 


Sequence # 


8 


Reserved 


24 


<Total Bits In MSG> 


160 



Table 2-21 

CT-RCP (Registration Complete) [MS-OTA <==> BS-OTA] 
Upon initial or periodic registration completion, the BS 
responds to the MS with a registration complete message. 





Information Element 


Length in Bits 






Message Type 


8 






Registration Status 


8 






Registration Timers 


8 






Cause 


8 






Registration Result 
Code 


8 . 






SBT 


120 






<Total Bits In MSG> 


160 




Table 2 
CT-REL (Release Link) 


S-22 

[MS-OTA < = > BS-OTA] 


Information Element 


Length in Bits 


Message Type 


8 


Cause 


8 


Reserved 


144 
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This message is sent by either the mobile 
communication transceiver 603 or the BS-OTA when the sending 
side released the connection in progress or during link setup. 

Table 2-23 

CT-RRQ (Registration Request) [MS-OTA => BS-OTA] 



15 



Information Element 


Length in Bits 


Message Type 


8 


Cipher Key 
Sequence # 


8 


Registration Type 


24 


Registration Status 


8 


Registration Info 


128 


< Total Bits In MSG> 


160 



A registration request shall be sent from a mobile 
communication transceiver 603 to a BS-OTA on an initial and a 

20 periodic basis. Upon the initial request, the base station 104 
shall enter the registration process. If the base station does 
not receive a periodic (30 seconds or as determined by the 
service provider) registration request from a mobile 
communication transceiver 603 which is currently registered with 

25 the base station, then the base station will initiate a de- 
registration procedure . 

Table 2-24 

CT-SPO (Specific Poll) [MS-OTA <==> BS-OTA] 
30 The CT-SPO is an invitation for only the MS identified by 

the FID Information Element to seize the indicated TDD channel 
(time slot) . It is generated by the BS in response to the 
Mobile Station's request to establish a link. 

35 
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30 



5 



10 



Information Element 


Length in Bits 


Message Type 


8 


Poll Type 


8 


PID 


72 


OTA Map Type 


8 


OTA Map 


32 


Reserved 


24 


Slot Quality 


8 


< Total Bits In MSG> 


160 



The mobile communication transceiver 6 03 sends the CT- 
SPR message to the BS-OTA in response to an unsolicited Specific 
Poll (i.e., one that is not part of link acquisition). This 
15 occurs when the base station 104 wishes to initiate a 

transaction (e.g., incoming call or special operation). 

Taible 2-25 

CT-SRQ (Service Response) [MS -OTA => BS-OTA] 

20 



25 



Information Element 


Length in Bits 


Message Type 


8 


TCID 


8 


Resource Request 
Data 


16 


Network Service 
Reserved Data 


128 


<Tot^l Bits In MSG> 


160 



30 

The mobile communication transceiver 6 03 sends the 
service request message to the BS-OTA to request call management 
access to the communication system 101. 

35 
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Table 2-26 

CT-SRS (Service Response) [MS-OTA <==> BS-OTA] 
The BS sends the CT-SRS message to the MS to inform the MS 
of the network's response to a Service Request. 



10 



15 



Information Element 


Length in Bits 


Message Type 


8 


TCID 


8 


Network Service 
Response 


24 


Cause 


8 


Reserved 


112 


< Total Bits In MSG> 


160 



Tcible 2-27.1 
CT-STIi (Set Link) [BS-OTA => MS-OTA] 



Information Element 


Length in Bits 


Message Type 


8 


Resource Request 
Data 


16 


OTA Map Type 


8 


OTA Map 


32 


Cause 


8 


TCID 


8 


Connection Number 


8 


Transport Method 


32 


Reserved 


24 


<Total Bits In MSG> 


160 



The BS-OTA sends the STL message to the mobile 
communication transceiver 6 03 when the BS-OTA wishes to change 
35 the characteristics of the over the air service across the O- 
Interface 610. 
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Table 2-27.2 
CT-STL (Set Link) [MS-OTA => BS-OTA] 



Information Element 


Length in Bits 


Message Type 


8 


Resource Recjues t 
Data 


32 


OTA Map Type 


8 


OTA Map 


32 


TCID 


8 


Reserved 


72 


<Total Bits In MSG> 


160 



15 The mobile communication transceiver 603 sends the CT- 
STL message to the BS-OTA when the mobile user station wishes to 
change the characteristics of the over the air service across 
the O-Interface 610. 



20 Ts±>le 2-28 

CT-SYN (Synchronize) [MS-OTA < = > BS-OTA] 



Information Element 


Length in Bits 


Message Type 


8 ^" 


Cipher Algorithm ID 


8 


Cipher Key 
Sequence # 


8 


Frame Number 


24 


Frame Offset 


8 


Cause 


8 


Reserved 


96 



<rotal Bits In MSG> 160 



35 Synchronize messages can be transmitted by either the 

BS-OTA or the mobile communication transceiver 603. They are 
always part of recovery from an error in a signaling 
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transaction. They are initiated by whichever side discovered 
the error. 

Table 2-29 
CT-THC (Terminating Handover Complete) 
[MS-OTA => Target BS-OTA] 



Information Element 


Length in Bits 


Message Type 


8 


Registration Type 


8 


Registration Status 


8 


Reserved 


136 


< Total Bits In MSG> 


160 



15 

The terminating Handover Complete message is sent from 
the mobile communication transceiver 603 to the target (new) 
base station to complete the Terminating Handover procedure. 

20 Tcible 2-30 

CT-THR (Terminating Handover Request) 
[MS-OTA => Target BS-OTA] 



Information Element 


Length in' Bits 


Message Type 


8 


Resource Request 


16 


(Old) Zone 


40 


(Old) BSC ID 


16 


(Old) BS ID 


32 


(Old) Connection 
Number 


24 


Reserved 


24 


<Total Bits In MSG> 


160 



35 

Handovers can, with certain limitations, be initiated 
either from the old base station 104 (an originating handover) 
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or the new base station 104 (a terminating handover) . The 
mobile communication transceiver 603 will attempt a terminating 
handover whenever possible because they are faster and more 
robust . The Terminating Handover Request message is sent from 
5 the mobile communication transceiver 6 03 to the target BS-OTA to 

initiate the terminating handover procedure. 



10 



Table 2-31 

CT-TRA (Transport Message) [MS-OTA <=> BS-OTA] 



Information Element 


Length in Bits 


Message Type 


8 


Transport Data 


152 



15 



< Total Bits In MSG> 



160 



The Transport Data includes the New Personal ID, Message 
Sequence number, and reserved bits, as below. 



Information Element 


Length in Bits 


Message Type 


8 


New Personal ID 


72 


Message Sequence 
Number 


8 


Reserved 


72 



< Total Bits In MSG> 160 



The Transport message transports bearer or user data 
3 0 between the BS-OTA and mobile communication transceiver 6 03 on 
the circuit specified by TCID (part of the Message Type for CT- 
TRA Notes) . 



35 
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Table 2-32 

CT-TSI (Time Slot Interchange) (MS-OTA => BS-OTA] 



Information Element 


Length in Bits 


Message Type 


8 


Reserved 


152 



A Time Slot Interchange request shall be sent from a 
mobile communication transceiver 603 to a BS-OTA when the mobile 

10 communication transceiver 603 determines that its signal quality 
might improve if it were communicating with the BS-OTA on 
different time slot(s). The BS-OTA will respond with a CT-STL 
message, giving the mobile communication transceiver 603 a 
different time slot map, if it can accommodate the TSI request. 

15 If the BS-OTA cannot accommodate the TSI request it will respond 
with a CT-HOF message. 

Table 2-33 
CT-UID {Update ID) [MS-OTA <= BS-OTA] 

20 



Information Element 


Length in Bits 


Message Type 


8 


New Personal ID 


72 


Zone 


4 0 


Reserved 


40 



<Tot^l Bits In MSG> 160 



Upon receipt of an Update ID N-Note from a base 
30 station controller 105, the base station 104 sends the mobile 
user station 102 a CT-UID message. 

The mobile communication system 101 transfers 
information in the form of signaling data and user data between 
a base station 104 and a base station controller 105 across an 
35 N- Interface 620. In a preferred embodiment, the N- Interface 620 
comprises one or more 64 kbps DSO lines between the base station 
104 and base station controller 105. In a presently preferred 
embodiment, a base station 104 and base station controller 105 
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communicate signaling data across a single dedicated 64 kbps DSO 
line, while user data is communicated across one or more 
separate 64 kbps DSO lines. Each DSO line operates according to 
the same protocol for the N- Interface 620. 
S Signaling data is communicated across the N- Interface 

620 according to a protocol described in CCITT Recommendation 
Q.920/Q.921 called "Link Access Procedures on the D-channel 
("LAPD") . LAPD is a subset of the ISO standard protocol High- 
level Data Link Control ("HDLC"). Further information regarding 

10 the LAPD protocol may be found in the CCITT IX Plenary Assembly 
Recommendations ("CCITT Blue Book"); Vol. VI, pp. 19-60, which 
is incorporated by reference as if set forth fully herein. 

Signaling data information is transferred over the N- 
Interface 620 in the form of N-Notes. Figure 11 is a diagram of 

15 a preferred format for a data frame 1105 which may be passed 
across the N- Interface 620 in the communication system 101. 
Each N-Note 1110 is encapsulated within a data frame 1105. 

Each data frame 1105 generally begins with an opening 
flag 1115 and ends with a closing flag 1120. The opening flag 

20 1115 and closing flag 1120 each comprise a predefined bit 

sequence (e.g., "01111110") which signals the beginning and end 
of a data frame 1105. A system component sending data across 
the N- Interface 620 examines the frame content between the 
opening flag 1115 and closing flag 1120, and inserts a 0-bit 

25 after all sequences of five consecutive 1-bits. A system 

component receiving data across the N- Interface 620 discards any 
0-bit which directly follows five consecutive 1-bits. 

The opening flag 1115 is immediately followed by an 
address field 1125 comprising, e.g., 16 bits. Figure 12 is a 

30 diagram of a preferred address field 1125 format. In the Fig. 

12 embodiment, the address field 1125 comprises a Service Access 
Point Identifier (SAPI) subfield 1210 comprising, e.g., 6 bits, 
a command/response (C/R) bit 1215, and a terminal endpoint 
identifier (TED subfield 1220 comprising, e.g., 7 bits. The 

35 address field 1125 also has two extension address (EA) bits 

1225, one in the first address field octet having a value of 0, 
and the second in the second address field octet having a value 
of 1. 
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The SAPI subfield 1210 identifies a protocol under 
which the current data frame 1105 operates. In one aspect, the 
SAPI subfield 1210 specifies an upper layer software entity for 
which the data carried by the current data frame 1105 is 
5 formatted. In a preferred embodiment, the N- Interface protocol 
may be specified by a SAPI subfield 1210 having a predefined 
value . 

The TEI subfield 1220 identifies a specific terminal 
endpoint which is the destination for the current data frame 
10 1105. Since the Q.921 link across the N- Interface 620 is 
actually a simple point-to-point connection between a base 
station 104 and a base station controller 105, only one TEI 
needs to be assigned to each physical interface in the mobile 
communication system 101. In a preferred embodiment, a unique 
15 TEI value is stored in each base station 104 and used during 
system initialization . 

The address field 1125 is followed by a control field 
1130 which identifies the type of frame as a command or response 
frame. The control field may be either a numbered information 
20 transfer (I), an unnumbered information transfer (U) , or a 
supervisory frame (S) . 

The control field 1130 is followed by an information 
field 1135 which contains an N-Note 1110. The information field 
1135 is followed by a frame check sequence 1140 comprising two 
25 eight-bit bytes. 

Table 3-1 through Table 3-3 9 describe exemplary N- 
Notes which may be communicated across the N- Interface 62 0 in a 
preferred embodiment of the communication system 101. In Table 
3-1 through Table 3-39, a base station 104 is denoted "BS" and a 
30 base station controller 105 is denoted "BSC." 



3NSDOCID: <WO 97l3353Al_t_> 



wo 97/13353 



38 



PCTAJS96/I5190 



Table 3-1 
Assist Information [BS <=> BSC] 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


Assist Type 


1 


Assist Data 


18 



10 

This message is sent either from the base station 104 
to the base station controller 105 or from the base station 
controller 105 to the base station 104 . It provides a mechanism 
to impart various items of information to assist the recipient 
15 in making well informed decisions. 



Table 3-2 
Assist Request [BS <=> BSC] 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


Channel Preference 


1 


Assist Type 


1 


Assist Request Info 


18 



This message is sent either from the base station 104 to 
the base station controller 105 or from the base station 
30 controller 105 to the base station 104 to request information. 

It provides a mechanism for the sender to request various items 
of information to assist in making well informed decisions. 



35 
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Table 3-3 
Authenticate [BS <= BSC] 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


TCID 


1 


Cipher Key Sequence # 


1 


Authentication Test 
Number 


16 



The Authenticate N-Note is sent to the base station 
104 from the network 12 6 to request that the base station 104 

15 send to the mobile user station 102 in an Authenticate O-Note. 
The mobile user station 102 will then encrypt the "random" 
number using the authentication key provisioned into the mobile 
station 102 and send this encrypted number back to the base 
station 104 in an Authentication Response Message (CT-AUR) 

20 reply . The base station 104 then sends this result to the 
network 126 in an Authentication Reply N-Note. 

Table 3-4 
Authenticate Reply [BS => BSC] 

25 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


Authentication Test 
Response 


16 



The Authenticate Reply N-Note from the base station 
35 104 to the network 126 is triggered by an Authentication 

Response O-Note (CT-AUR) from the mobile user station 102. The 
Authenticate Reply N-Note communicates a sixteen octet: encrypted 



BNSDOCID; <WO 9713353A1. r . > 



wo 97/13353 PCT/US96/15190 

40 

response from the mobile user station 102 to the network 126 for 
confirmation. The network 126 will perform encryption on the 
original random number and compare the results for 
authentication. The Authenticate Reply should be the response 
5 to an earlier Authenticate N-Note issued for the given PID by 
the network 126 . If the return value is incorrect , the proper 
response of the network 126 is to deny access by the mobile 
user station 102 . 



10 Table 3-5 

Authentication Reject [BS <= BSC] 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


TCID 


1 


Cause 


1 



20 

The Authentication Reject N-Note is sent to the base 
station 104 from the network 126 to inform the mobile user 
station 102 that the network 126 has rejected its Authenticate 
Reply. 

25 

Table 3-6 
Base Status Request IBS <= BSC] 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


CI 


1 


Base ID 


4 


Base Status 


32 
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The Base Status Request N-Note is sent to the base station 
104 by the network 126 to initiate a Base Status Response N-Note 
from the base station 104 . 

Table 3-7 
Base Status Response [BS => BSC] 



10 



15 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


Base ID 


32 



The Base Status Response N-Note is sent to the network 
126 by the base station 104 after receiving a Base Status 
Request N-Note from the network 126. 



20 



Table 3-8 
Cipher Response [BS => BSC] 



25 



30 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


Cause 


2 



The Cipher Response N-Note is sent to the network 126 
to inform it that the base station 104 and mobile user station 
102 have configured and keyed their encryption equipment and 
have enabled the equipment . 



35 
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Table 3-9 
Circuit Switch Complete [BS <= BSC] 



J. nx Oiinau ion CiXemenc 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


(New) Zone 


5 


(New) Base ID 


4 


HRef 


6 



The Circuit Switch Complete N-Note is sent to the 
originating base station 104 from the network 126 when a 

15 handover circuit switch operation has completed. This message 

informs the originating base station 104 that the bearer channel 
has been switched from the originating base station 104 to the 
terminating base station 104 and that the originating base 
station 104 may release all the resources associated with the 

20 mobile user station 102. 



Table 3-10 
Circuit Si^itch Refused [BS => BSC] 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


(New) Zone 


5 


(New) Base ID 


4 


HRef 


6 



The Circuit Switch Refused N-Note is sent to the 
35 network 126 from the originating base station 104 when the 
mobile user station 102 has rejected the circuit switch . 
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Table 3-11 
Connect Link [BS => BSC] 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


TCID 


1 



The Connect Link N-Note is sent from the base station 
104 to the network 126 as the result of a CT-CNL message 
received from an mobile user station 102 while the base station 
104 and mobile user station 102 are in a HOLD sequence initiated 
15 during an incoming call. The CT-ACK control traffic will be 

returned from the mobile user station 102. This message informs 
the network 126 that it may complete the connection with the 
calling station. 

20 Table 3-12 

Connect Link [BS <= BSC] 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


TCID 


1 


Connection Number 


3 


Cause 


1 



The Connect Link N-Note is sent to the base station 
104 from the network 126 when a connection has been made to 
another station via the network 126. This message associates 
35 the PID of an mobile user station 102 with a Connection Number. 
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Table 3-13 
Connection Complete [BS <= BSC] 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


TCID 


1 


Cipher Algorithm ID 


1 


Cipher Key 


8 


Connection Number 


3 



The Connection Complete N-Note is sent to the 
termination base station 104 from the network 126 when a 
handover circuit switch operation has completed. This message 
informs the terminating base station 104 that the bearer channel 
has been switched from the originating base station 104 to the 
terminating base station 104 . 



Table 3-14 
Deregister [BS => BSC] 



Inf oirmation Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


Class 


2 


Cause 


1 



The Deregister N-Note is issued from the base station 
104 to the network 126 as the result of either a DRG control 
traffic response message or a base station time-out, which 
indicates that the identified mobile user station 102 is no 
longer in the response range of the base station 104 . The 
proper response of the network 126 is to release all resources 
which may have been preallocated to the mobile user station 102 , 
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Table 3-15 
Handover Failure [BS <= BSC] 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


Cause 


1 



10 The Handover Failed N-Note is sent to both the source 

and target base stations 104 from the network 126 when the 
higher order network infrastructure has rejected the terminating 
or originating handover request from the mobile user station 
102. Each base station must send a CT-HOF O-Note to the mobile 

15 user station 102 if/when it communicates with the mobile user 
station 102. The source base station 104 will maintain the 
existing connection to the mobile user station 102; the target 
base station 104 will release the connection with the mobile 
user station 102 after sending the CT-HOF. 

20 

Table 3-16 
Handover Request [BS <= BSC] 



I n f or ma t i on E 1 emen t 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID (HRef) 


9 


CI 


1 


TCID 


4 


Connection Number 


3 


Cipher Algorithm ID 


1 


Cipher Key 


8 


Resource Request 
Data 


2 


Transport Method 


4 
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The Handover Request N-Note is sent to the target base 
stations from the base station controller when the higher order 
network infrastructure is attempting to perform an originating 
handover request from the mobile user station 102. The target 
base station 104 will reserve the requisite resources for the 
circuit being handed over, if available, and will respond to the 
base Stat ion controller 105 with a Handover Request ACK message. 



10 



Table 3-17 
Handover Request Reply [BS => BSC] 



15 



20 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID (HRef) 


9 


CI 


1 


Backhaul Map Type 


1 


Backhaul Map 


4 


Cause 


1 



25 



The Handover Request Reply N-Note is sent to the base 
station controller 105 in response to the Handover Request 
message. 

Table 3-18 
ID Updated [BS <=> BSC] 



30 



35 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


Cause 


1 
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The ID Updated N-Note is sent by the base station 104 

to the network 126 to indicate the successful updating of an 
mobile user station PID. 

5 Table 3-19 

Identity Reply [BS => BSC] 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


CI 


1 


Identity Type 


1 


Identity Data 


9 


Message Sequence 
Number 


1 



The Identity .Reply N-Note is sent by the base station 
20 104 to the network 126 to provide the mobile user station' s 
requested identity . 

Table 3-20 
Identity Request [BS <= BSC] 

25 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


CI 


1 


Identity Type 


1 



The ID Updated N-Note is sent by the network 126 to 
35 the base station 104 to request a mobile user station identifier 
that has not been provided as part of the mobile user station's 
normal communications with the network 126. 
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Table 3-21 
Originating Handover [BS => BSC] 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


CI 


1 


Remaining Base 
Count 


1 


(New) Zone 


5 


(New) BSC ID 


2 


(New) Base ID 


4 



15 

The Originating Handover N-Note is sent from the base 
station 104 to the network 126 after an mobile user station 102 
has returned to the originating base station 104 and has 
completed the originating handover control traffic sequence. 
20 This message contains the PID of the mobile user station 102, 
the base station ID and Zone of the terminating base station 
104. This information is to be used by the network 126 to 
establish a bearer connection to the terminating base station 
104. The network 126 should respond to the originating base 
25 station 104 with a Circuit Switch Complete N-Note signifying 
that the terminating base station 104 is now connected to the 
proper bearer channel . 

Provision is made for this message to provide a list 
of base stations 104 the mobile user station 102 is willing to 
30 handover to. This allows the potential ability for the mobile 
user station 102 to signal the base station 104 , as part of the 
CT-OTH message, that there are several acceptable alternatives 
and to send each of them to the originating base station 104 as 
sequential CT-OTH messages. The base station 104 may accumulate 
35 the acceptable base station list and send it to the base station 
controller 105 in a single message. The Count Base field lists 
the number of base stations 104 in the list. 
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Table 3-22 

Originating Handover Complete [BS => BSC] 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID (HRef) 


9 


CI 


1 


PID (Real) 


9 



The Originating Handover Complete N-Note is issued 
from the terminating base station 104 to the terminating 
application end user (e.g., network 126) connected to the base 

15 station controller 105 when a mobile user station 102 has 
completed its transfer of its bearer traffic from the 
originating base station 104 to the terminating base station 
104. This happens when the mobile user station 102 issues a 
Originating Handover Complete control traffic message to the 

20 texTuinating base station 104. 



Table 3-23 
Page [BS <= BSC] 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


CI 


1 


TCID 


1 



The Page N-Note is sent to the base station 104 from the 
network 126 to notify the base station 104 of an incoming call. 
35 The base station 104 should initiate a Specific Poll sequence 
for the mobile user station 102 named by the PID. When the 
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mobile user station 102 responds to the Specific Poll, the base 
station 104 should send an Altering N-Note back to the network 
126 . 

5 Table 3-24 

Page Response [BS => BSC] 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


CI 


1 


TCID 


1 


Cipher Key 
Sequence # 


1 


Class 


2 



The Page Response N-Note is sent from the base station 

20 104 to the network 126 as soon as a specific 

poll response, which is the result of an Setup N-Note initiated 
specific poll, is received from the mobile user station 102 
named by the PID. This notification can be used by the network 
126 to indicate a successful attempt to find, a specific mobile 

25 user station 102. If the network 126 does not receive Page 

Response from the base station 104 sometime after the network 
126 has sent a Setup N-Note to the base station 104, the network 
126 may infer that the given mobile user station 102 is not 
currently reachable through this base station 104 . Being 

30 unavailable should trigger a Deregistration sequence. 



35 
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Table 3-25 
Register [BS <= BSC] 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


Registration Type 


1 


Registration Info 


18 


Cipher Key Sequence 
# 


1 


Class 


2 



15 The Register N-Note is sent to the network 126 from 

the base station 104 as a result of the completion of an acquire 
and registration poll and control traffic sequence between the 
mobile user station 102 and the base station 104. This message 
requests that resources needed to access application end user be 

20 allocated in the network 126 for this mobile user station 102. 

If these resources have already been allocated, then the network 
126 should not allocate new resources. In any event, the 
network 126 should reply with a Registration Result N-Note. 

25 Table 3-26 



Registration Result [BS <= BSC] 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


CI 


1 


Follow On Proceed 


1 


Registration Result 
Code 


1 


Cause 


1 
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The Registration Result N-Note is sent to the base 
station 104 from the network 126 when the higher order network 
infrastructure responds to the mobile user station's Register 
request . 

5 

Table 3-27 
Release Link [BS <= BSC] 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


CI 


1 


TCID 


1 


Causes 


1 



The N-Note Release Link is sent by either the base 
station 104 or the network 126 to indicate that the sender 
20 wishes to release the link. If the TCID is non-zero, the 
Release Link is for a virtual circuit and the request is 
ignored- If the TCID is zero, a Release Link Complete message 
is always sent (even if recipient does not recognize the PID) . 

25 Table 3-28 



Release Link Complete [BS <= BSC] 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


CI 


1 


TCID 


1 



35 The Release Link Complete N-Note is sent by either the 

base station 104 or the network 126 to indicate that the sender 
has released the channel and the TCID. 
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Table 3-29 
Service Information [BS <= BSC] 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


CI 


1 


Backhaul Map 
Type 


1 


Backhaul Map 


4 


(OTA) Channel 
Rate 


1 


Cause 


1 



The Service Information N-Note is sent from the base 
station 104 to the network 126. This message informs the 
network 126 of the bearer channels that have been assigned by 
20 the base station 104 for this call. 



Table 3-30 
Cipher Mode [BS <= BSC] 



25 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


CI 


1 


Cipher Algorithm ID 


1 


Cipher Key 


8 


Request PID Type 


1 



The Set Cipher Mode N-Note is sent from the network 126 to 
the base station 104. It requests the base station 104 to set 
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the mode key and key sequence of its encryption equipment. The 
base station 104 does not enable its encryption equipment at 
this time. 

5 Taible 3-31 

Service Request [BS => BSC] 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


CI 


1 


TCID 


1 


Resource Request 
Data 


2 


Network Service 
Request Data 


16 



20 The Service Request N-Note is sent to the network 12 6 the 

base station 104 upon the completion of CT-SRQ control traffic 
exchange. Failure to respond will result in dropping the 
connection between the base station 104 and mobile user station 
102. 

25 



30 



35 



MSDOCID: <WO 9713353A1_L> 



wo 97/13353 



PCT/US96/15190 



55 

Table 3-32 
Service Response [BS <= BSC] 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


CI 


1 


TCID 


1 


Network Service 
Response 


3 


Cause 


1 



The Service Response N-Note is sent to the base station 104 
by the network 126 to notify the base station 104 of the results 
of the base station's Service Request message. 



Table 3-33 

2 0 Set Link [BS <== BSC] 



25 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


CI 


1 


TCID 


1 


Resource Request 
Data 


2 


Connection 
Number 


3 


Transport Method 


4 
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The Set Link N-Note is sent to the base station 104 
from the network 126 to notify the base station 104 of a SETUP 
message from the network 126. 



5 Table 3-34 



Terminating Handover [BS => BSC] 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


CI 


1 


(Old) Zone 


5 


(Old) BSC ID 


2 


Connection 
Number 


3 


(New) Backhaul 
Map Type 


1 


(New) Backhaul 
Map 


4 



The Terminating Handover N-Note is sent from the base 
station 104 to the network 126 after an mobile user station 102 
has acquired a base station channel (i.e., time slot) on the 
25 terminating base station 104 and has completed the Terminating 
Handover Request Control Traffic sequence. This message 
contains the PID and Universal Phone number of the mobile user 
station 102, as well as the Connection Number, Zone and base 
station controller ID of the base station controller which had 

30 been previously carrying the connection. This information is 

used by the network 126 to establish a bearer connection to the 
previous connection and to inform the old base station 104 to 
x-elease its connection and the resources allocated to this 
mobile user station 102. Within a reasonable amount of time, 

35 the network 126 should respond to the base station 104 with a 

Circuit Switch Complete N-Note signifying that this base station 
104 is now connected to the proper bearer channel. 
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Table 3-35 

Terminating Handover Complete [BS => BSC] 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 



10 The Terminating Handover Complete N-Note is issued 

from the terminating base station 104 to the terminating 
application end user connected to the base station controller 
105 when a mobile user station 102 has completed its transfer of 
its bearer traffic from the originating base station 104 to the 

15 terminating base station 104. This happens when the mobile user 
station 102 issues a Terminating Handover Complete O-Note to the 
terminating base station 104 . 

Table 3-36 

2 0 Transfer Complete [BS => BSC] 



Inf ormat ion Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


CI 


1 



The Transfer Complete N-Note is issued from the base 
30 station 104 to the network 126 when a mobile user station 102 
transfers its bearer traffic from the originating base station 
104 to the terminating base station 104. This is assumed to 
occur when the originating base station 104 sends a Circuit 
Switch Complete (CSC) O-Note to the mobile user station 102. 

35 
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Table 3-37 
Transport [BS <=> BSC] 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


CI 


1 


TCID 


1 


Channel 
Preference 


1 


TC Data Length 


2 


TC Data 


<variable> 



15 The Transport N-Note is sent from the base station 104 

to the network 126 to send signaling or bearer data to the 
network 126 . 

Table 3-38 

2 0 Transport Delivered [BS <== BSC] 

The Transport Delivered Note is sent from the BS to the 
Network Application to signal the Network Application that all 
segments of the Transport Note have been delivered send 
signaling data to the Network Application. 

2 5 The Transport Delivered Note is triggered by an ACK 

(successful ARQ) of the final segment (CT-TRA) of the Transport 
Note over the O- Interface. It does not imply delivery of the 
Transport Note to the ultimate receiver, it simply confirms that 
the entire Transport Note has been delivered over the O- 

30 Interface. 

The Transport Delivered Note provides the BSC with 
confirmation that the Transport Note has actually been delivered 
over the radio link. If it doesn't receive this confirmation 
(e.g., because of the handover) it will re-send the message. 

35 This mitigates the problem of only getting part of a Transport 

Note over the air before a handover occurs. Note that while the 
BSC can not send another Transport Note for a given TCID during 
the interval while it is waiting for the Transport Delivered on 
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the last Transport Note to that TCID, it may send another 
N__Notes or a Transport Note to a different TCID. 



15 



Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


CI 


1 


TCID 


1 


Cause 


1 


Table 3-3 9 
Update ID [BS <= BSC] 


Information Element 


Length in Octets 


Protocol 


1 


System Type 


1 


Message Type 


1 


PID 


9 


CI 


1 


(New) PID 


9 


Zone 


5 



The Update ID N-Note is sent to the base station 104 
25 from the application end user connected to the base station 
controller 105 to notify the base station 104 to update the 
identity of the mobile user station 102 described by the PID 
information element- The New PID information element may 
represent a temporary identification for the mobile user station 
_ 30 102 as provided for in the definition of the New PID. 

The mobile communication system 101 transfers 
information in the form of signaling data within the base 
station 104 between the base station transceiver 604 and the 
base station line card processor 606 across the I -Interface 615 
35 in the form of I -Notes. Figure 8 is a diagram of the Fig. 6 
system architecture focusing on the base station interfaces, 
showing the separation between the base station transceiver 604 
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and the line card processor 606. The base station transceiver 
604 and the line card processor 606 preferably each has its own 
local microprocessor or controller, and its own resident 
software . 

5 Figure 9 is a diagram illustrating a breakdown of 

software functionality for operations, administration, 
maintenance and provisioning (OAM&P) within a base station 104 . 
In Fig. 9 is shown a functional division between base station 
transceiver software 909 and the line card processor software 

10 908. The base station transceiver software 909 and line card 
processor software 908 are directed to the control of managed 
objects. The line card processor software 908 is responsible by 
itself for the control of a base station manager managed object 
920, and shares responsibility with the base station transceiver 

15 software 909 for control of a base station managed object 921, 
transceiver managed objects 922. and channel managed objects 
923 . 

The base station manager managed object 920 is 
responsible for communication of high layer information between 
20 the base station 104 and the base station controller 105. and 

for the management of all functionality related to the line-card 
processor 606. The base station managed object 921 provides the 
OAM&P control functions common to one or more transceivers, and 
is responsible for all OAM&P base station functionality other 
25 than the line card processor 606. The transceiver managed 
objects 922 are responsible for the management of the base 
station equipment that provides the time slot structure shown in 
Fig. 3, including modulation and transmission of information 
data as well as reception and demodulation. The channel managed 
objects 923 are responsible for the management of individual 
physical channels (i.e., separate time slots 302). 

Control of the OAM&P functions are carried out across 
the OOMT interface between the base station controller 105 and 
the base station 104 shown in Fig. 6. 

In a preferred embodiment, the I -Interface 615 
includes a dual port random access memory (RAM) . Figure 14 is a 
high-level diagram of a base station 104 including a dual -port 
RAM 1401 for implementing the I -interface 615. Application 
information 1407, 1408 is communicated across the I -interface 



30 



35 
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using the dual-port RAM 1401. The base station transceiver 604 
and line card processor 606 each comprise an I -interface manager 
14 05 and 14 04, which may be implemented as software subroutines. 
The I-interface managers 1404, 1405 facilitate transfer of 
5 information across the I-interface 615. 

The physical interface to the dual-port RAM 1401 is 
preferably identical for both the base station transceiver 604 
and the line card processor 606. The base station transceiver 
604 comprises boot code 1409 (in addition to operational code) ; 
10 thus, two modes of use are provided: (1) a non-operational mode, 
wherein the dual-port RAM 1401 may be used for initialization of 
the base station transceiver 604 (including software download 
from a base station controller 105, if desired), and (2) an 
operational mode, wherein the dual -port RAM 14 01 is used for 
15 transfer of information to and from an application end user 602 
using the I-interface 615. 

The dual port RAM 14 01 comprises a common memory which 
may be accessed by both the line card processor 606 and the base 
station transceiver 604 in the base station 104. The line card 
20 processor 606 and the base station transceiver 604 transfer 

information across the I -Interface 615 by reading and writing I- 
Notes to the common dual port RAM 1401. The dual port RAM 1401 
is also used for transfer of bearer information for each of the 
time slot channels, and thus comprises adequate storage to 
25 transfer data blocks to and from mobile user stations 102. 

Alternatively, the bearer data could be provided in a direct 
link to the line card processor 606 from the base station 
transceiver 604 . 

System requirements may specify that certain events or 
30 messages have a greater priority over other events occurring in 
the system. For example, handoff events or emergency events may 
have a relatively high priority. Call control events may also 
have a relatively high priority, but less than that of handoff 
events or emergency events. Application messages may be given a 
35 lower priority than signaling messages. 

The I-interface may be configured so as to facilitate 
prioritization of various events and system messages. A 
plurality of distinct priority groups may be defined. In a 
particular embodiment, three priority groups are defined, a high 
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priority group including, e.g., handoff events and emergency 
events, a medium priority group including, e.g., communication 
management events and call control messages, and a low priority 
group including other types of less urgent messages. 

A plurality of prioritized queues may be provided, 
each prioritized queue associated with one of the three priority 
groups. Each prioritized queue comprises a plurality of message 
buffers (preferably fixed length message buffers) . Messages 
from the high priority group are placed in a first queue; 
messages from the medium priority group are placed in a second 
queue; and messages from the low priority group are placed in a 
third queue. The I -interface managers 14 04, 14 05 keep track of 
the prioritized queues and handle message transfers to and from 
the queues . 

The queues may each operate on a "first -in first -out" 
(FIFO) basis. Where several messages are to be aggregated for 
delivery or reception over a particular channel (e.g., time 
slot) , each channel may be provided with its own individual 
FIFO. Both "send" and "receive" queues are provided for bi- 
directional transfer of information. 

The I -interface managers 14 04, 14 05 each implement at 
least three software functions with respect to the prioritized 
queues. A first software function returns a pointer to the next 
available send NOTE buffer in the designated queue. A NULL 
25 return pointer indicates that the queue is full. A second 

software function activates any semaphore and updates pointers 
for a queue acting on the current send NOTE buffer. A zero 
return value indicates success. A third software function 
returns a pointer to the next available NOTE buffer in the 
30 designated queue. A NULL return pointer indicates that the 
queue is full. 

Figure 15 is a table of an exemplary partial map for a 
dual-port RAM 1401. The dual port RAM map includes the total 
number of prioritized queues and, for each queue, the address of 
35 a read ("get") pointer, the address of a write ("put") pointer, 
the start address of the queue, and the queue length. 

The dual -port RAM 1401 is used for both bearer data 
message transfer and prioritization of certain signaling 
messages. Bearer data messages are stored in predefined 



20 
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locations in the dual-port RAM 1401, and can be accessed by 
either the line card processor 606 or the base station 
transceiver 604. The dual-port RAM 1401 may preferably hold at 
least 2,304 bearer-bytes of information (for a base station 104 
5 supporting up to 32 user stations 102) , and has an additional 32 
kilobytes for the prioritized queues. 

Figure 16A is a block diagram of a base station 1601 
in accordance with one embodiment of the present invention. In 
Fig. 16, a dual-port RAM 1609 (e.g., dual-port RAM 1401 of Fig. 

10 14) comprises a plurality of queues 1615, 1616, and 1617, and 

buffers 1620, 1621 for storing messages originating from and 
destined for user stations 102. An over-the-air (OTA) interface 
1607, under control of an OTA controller 1606, transmits and 
receives messages from user stations 102. A line card interface 

15 1611, under control of a line card controller 1610, transmits 

and receives messages from a base station controller 105 (see 
Fig. IB) . A base station global bus controller 1605 controls 
mode selection of the OTA controller 1606 and line card 
controller 1610, handles interrupts, and responds to commands 

20 from the system regarding operation of the base station 1601 as 

a whole (e.g., whether the base station 104 should be on-line or 
off-line , etc . ) . 

Figure 16B is a more detailed diagram of internal 
components of the base station 1601, showing the internal 

25 components and connections of the components shown in Fig. 16A, 
The Fig. 16B diagram shows a global bus 163 0 connected to 
several of the internal components, as well as backhaul lines 
1650 from the line card interface 1611 which ultimately connect 
to the base station controller 105. 

3 0 Figure 17A is a diagram of an exemplary memory map for 

the dual-port RAM 1401, not considering the map portion for the 
prioritized queues shown in Fig. 15. Figure 17B is an 
alternative memory map for the dual -port RAM 1401, and is 
configured for analog backhaul lines from the base station 104 

35 to the base station controller 105. 

In a preferred embodiment, the communication system 
101 uses I -Notes having the same format as the N-Notes as shown 
in Fig. 11. Examples of I -Notes which may be communicated 
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across the I-Interface are given in Table 3-1 through Table 3-39. 

Because messages to and from the user stations 102 are 
generally not in the form of I -Notes, the base station 
transceiver 604 translates relevant portions of the over-the-air 
5 messages into an I -Note format, and either uses or sends I -Notes 
received from the line card processor 606 across the I-interface 
605, If an O-Note is contained in a B-field 529 of a user 
message (as indicated by a flag in the header 523), then the 
base station transceiver 604 extracts the O-Note and places it 

10 in one of the three queues 1615, 1616 or 1617. If an O-Note is 

contained in segments within D-fields 527 sent over several 
messages, then the base station transceiver 604 may store the O- 
Note in a buffer associated with the user station 102 on the 
particular channel until the entire O-Note is received, and then 

15 place the entire O-Note in the appropriate one of the three 
queues 1615, 1616 or 1617. In some cases, the base station 
transceiver 604 performs a translation (or removes or adds 
fields or other information) before storing the message (now an 
I -Note) in the appropriate queue 1615, 1616 or 1617. 

20 Similarly, when the base station transceiver 604 reads 

an I -Note from the dual -port RAM 1609, it may perform a 
translation of the I -Note (or remove or add fields as necessary) 
and insert the message (now an O-Note) in the B-field 559 of a 
base message , and indicate the presence of an O-Note by setting 

25 the appropriate flag in the base message header 553. If the O- 
Note does not represent a relatively urgent signaling message, 
and voice data or other user data is being sent in the B-field 
559, the base station transceiver 604 may send the O-Note in 
segments over a plurality of base messages, utilizing the D- 

30 field 557. 

In a preferred embodiment, the communication system 
101 operates with Notes which contain common Information 
Elements which may be passed across several system interfaces. 
Table 4-1 through Table 4-6 5 describe Information Elements which 
3 5 may be included in Notes which are communicated across system 
interfaces in a preferred embodiment of the communication 
system 101. Information Elements may comprise signaling data 
which is used by components within the communication system 101 
to perform functions in support of one or more application end 
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users. A specific Information Element, referred to as Transport 
Data, comprises application level data and is described in Table 
4-62 . 

Table 4-1 
ACK'ed Command [0,M] 

The ACK'ed Command information element contains the 
Type of the specific command being acknowledged. The values are 
the same as the Message Type on the given interface. 



10 



15. 



Bits 
4 3 



ACK'ed Command 



Octets 



20 



Table 4-2 
ACK Response lO,M] 
The ACK Response information element contains the 
acknowledgment response . 



25 



Bits Octets 
87654321 



ACK ' ed Response 



30 



35 



ACK Response 



0 


Successful acknowledge 


1 


Unsuccessful acknowledge (NAK) 


2-255 


Reserved 



Table 4-3 
Assist Data [O, M, N, I] 
The Assist Data element is a 144 bit field that is 
used by the sender to pass information to the receiver. This 
information may or may not have been solicited by an Assist 
Request. The format and meaning of the Assist Information is 
dependent upon the Assist Type . 
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Bits 
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Octets 



144 bit Assist Data 



Table 4-4 



1 
2 
3 
4 



18 



15 



20 



25 



30 



35 



Assist Request Info 
The Assist Request Info element is a 144 bit field 
that is used by the sender of an Assist Request to provide 
additional information identifying the request. The most likely 
use of this element will be to provide a PID when requesting 
information about a specific user station 102. This information 
element also contains the identity of the requester so that the 
requester can be named as the recipient of the Assist 
Information message which results from this request. The format 
and meaning of the Assist Request Info is dependent upon the 
Assist Type. 



Bits 
5 4 3 



Assist Requester 



141 bits Assist Request Info 



Octets 

1 
2 
3 
4 



18 
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Same values and meanings as the Assist Msg Recipient 
subfield of the Assist Type information element. 

Table 4-5 

Assist Type [O, M, N, I] 
The Assist Type is divided into two subf ields , 



10 



Bits 
6 5 



Octets 





Assist Msg 


Assist Item 


1 




Recipient 






15. 




Table 4-5.1 








Assist Item 





Identifies the Information being Requested. 



20 



Assist 
Type 


Information 
Source 


Item 


0 




Reserved 


1 


BS-OTA 


Surrounding Base Table 


2, 


BS-OTA 


Surrounding Base Table 
( Cont inuat ion ) 


3 


BS-OTA 


Recommend Time Slot Interchange 


4 


BS-OTA 


Recommend Handover 


5 


BS-OTA 


Date & Time 


6 


BS-OTA 


OTA Map 


7 


BS-OTA 


Backhaul Map 


8 


BS-OTA 


Distance from BS to BS 


9 


BSC 


Date & Time 


10 


BSC 


Code - Frequency Rede f ini t ion 


11-31 




Reserved 



25 



30 
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Table 4-5.2 



Assist Msg Recipient 



5 Identifies the recipient of the assist message. if 

the message is an Assist Request message, then the recipient is 
the Information Source (i.e., the process which provides the 
information) . If the message is an Assist Information message, 
then the recipient is the Information Destination (i.e., the 

10 process which may use the information) . If the Assist 

Information message was requested, the Assist Message Recipient 
will be the Assist Requester subfield of the Assist Request Info 
information element of the Assist Request message is 
unsolicited, the sender will be able to supply the Assist 

15 Message Recipient independently. 



The following recipients are defined: 



20 



0 


MS-APP 


1 


MS -OTA 


2 


BS-OTA 


3 


BS-Line Card 


4 


BSC 


5-7 


Reserved 



Table 4-6 



Authentication Test Number [O, M, N, I] 



The Authentication Test Number information element 
contains a 16 byte (128 bit) value to be used in authenticating 
an user station 102 . 



35 
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Table 4-6.1 

Key Type is DCS1900: 

If the Protocol of an Authenticate message is DCS1900, 
then the authentication parameter is a 128 bit pseudo random 
number which is sent to the user station 102 for the 
authentication process . 



Bits 



Octets 



10 



15 



20 



25 



12 8 bit Pseudo Random Number 



1 
2 
3 
4 
5 
6 
7 
8 
9 

10 
11 
12 
13 
14 
15 
16 



30 



Table 4-6.2 



Protocol i s Bellcore 



If the Protocol is Bellcore "C", then the 
35 authentication parameter is RAND (a random number) , 64 bits of 
which are to be used by the base station 104 in the 
authentication process . 
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Bits 



Octets 



87654321 



64 bit RAND 



10 



15 



Reserved 



Reserved 



20 



1 
2 
3 
4 
5 
6 
7 
8 
9 

10 
11 
12 
13 
14 
15 
16 



Table 4-7 

Authentication Test Response [O, M, N, I] 

25 

The contents of the Authentication Test Response 
information element depends upon the infrastructure of the 
system. If the Authenticate N_Notes RMT message' that stimulated 
the response was of type DCS1900, then the contents is the 32 
3 0 bit result of applying the authentication algorithm to the 

pseudo-random number supplied. If the Authentication N_Notes 
RMT message was of Bellcore "C" type, then a single bit of the 
result signifies either successful authentication or failure. 

35 
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Table 4-7.1 
DCS1900 Response 
Bits 

6 5 4 3 



Response Data 



Response Data 



Response Data 



Response Data 



Reserved 



Reserved 



Table 4-7.2 



IS -54 Response 



Octets 

1 

2 
3 
4 
5 



16 



Result 



Bits 
5 4 



Result 



Reserved 



Reserved 



0 


Authentication Success 


1 


Authentication Failure 


2-255 


Reserved 



Octets 

1 

2 
3 
4 
5 



16 
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Table 4-8 
Auth Type [O] 

The Authentication Type information element defines 
the type of infrastructure that is providing the authentication 
procedure . 



10 



Bits 



Octets 



Auth Type 



15 



20 



Auth Type 



0 


DCS1900 Authentication 


1 


Bellcore Generic C Authentication 


2-255 


Reserved 



25 



30 



Table 4-9 
High Bandwidth Bearer data 
Bits 

6 5 4 3 2 1 



<TBD> bits of bearer data 



Octets 

1 
2 



<TBD> 



35 
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Table 4-9.1 



Low Bandwidth Bearer Data 



10 



15 



The Low Bandwidth Bearer Data Element consists of 
fewer bits of user data than the High Bandwidth Bearer Data 
Element. Data transmitted via this mode may suffer temporal 
distortion but will be correctly delivered with no undetected 
lost or duplicated packets to the limits of the FCW algorithm. 



Bits 
5 4 



<TBD> bits of bearer data 



Octets 

1 

2 



<TBD> 



20 

Table 4-9,2 
Symmetric Bandwidth Bearer Data 

25 The Symmetric Bandwidth Bearer Data Element consists 

of 192 bits of user data. The low order bit of the 192 bit 
number resides in Bit 1 Octet l while the high order bit of the 
192 bit number resides in Bit 8 of Octet 24. Data transmitted 
via this mode may suffer temporal distortion but will be 

30 correctly delivered with no undetected lost or duplicated 
packets to the limits of the FCW algorithm. 



35 



3NSDOCID: <WO 9713353A1_I_> 



wo 97/13353 



PCT/US96/15I90 



74 



Bits 



Octets 



10 



192 bits of bearer data 



1 

2 



24 



Table 4-10 



15 



20 



25 



Backhaul Map [N, I] 

The Backhaul Map information element details the 
allocation of backhaul channels on the backhaul link between the 
base station 104 and the base station controller 105. There are 
two types of Backhaul Maps. The first is the Superframe 
Backhaul Map, which consists of a bit map showing the specific 
backhaul channels assigned to the MS represented by the Personal 
ID associated with the N_Notes RMT message in which the Backhaul 
Map appears. The second type is the Subframe Backhaul Map, 
which identifies a single backhaul channel and the 
submultiplexing rate to be applied to the channel. 

When the Backhaul Map Type is Superframe: 



30 



8- 



Bits 
7 6 



3 2 bits of backhaul channel absolute position 



Octets 

1 
2 
3 
4 



35 
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When the Backhaul Map Type is Subframe: 

Bits 

8 7 6 5 4 3 



8 bits Backhaul channel # 



Multiplex rate 



Multiplex rate offset 



Reserved 



Octets 

1 
2 
3 
4 



Reserved (transmitted) bits are always set to zero and 
received reserved bits are also ignored. 

The multiplex rate defines the number of channels to 
be allocated. Multiplex Rates Offset specifies the relative 
frame position to the next channel to be used. One indicates 
transmission in the next channel . 



15 



Table 4-11 



Backhaul Map Type [N, I] 

20 The Map Type information element is used to define the 

type of Backhaul Map that follows. There are two types of 
Backhaul Maps: Superframe and Subframe. Superframe maps detail 
the assignment of one or more complete 9.6 kbps backhaul 
channels in the base station 104 to base station controller 105 

25 backhaul link to a single call. Subframe maps describe the 
submultiplexing characteristics of a less than 9.6 kbps rate 
onto a single 9.6 kbps backhaul channel. 



30 



Bits 

5 



Octets 



8 bit Map Type 



Map Type 



0 


No Map 


1 


Superframe 


2 


Subframe 


3-255 


Reserved 
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If Backhaul Map Type indicates No Map, then the 
Backhaul Map should be zero. 

Table 4-12 



10 



Base ID [O, M, N, I] 
The Base Identifier, in conjunction with the PLMN, 
uniquely identifies the specific base station 104. The low 
order bit of the 32 bit number is located in Bit 1 Octet 1. The 
high order bit of the 32 bit number is located in Bit 8 of Octet 
4 . 



15 



20 



8 



Bits 
5 



32 bits of unique Base Identification 



(2 octets) 



Cell Size ID 



Cell Size ID/Pole Position/TRX Unit 



Table 4-13 



Octets 

1 
2 
3 
4 



25 



Base St:atus [N, I] 
The Base Status information element is comprised of 32 



octets . 



Bits Octets 
87654321 



30 



35 



32 Octets of Base Status 



1 

2 



32 
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20 



25 
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Table 4-14 
Base ID: Cell Site ID 
The Cell Site ID Field consists of 10 bits which are used 
to identify a particular physical cell site within the Zone, 
(e.g., a particular "light pole".) 



0 


Cell Site ID 


1 


Cell Site ID 






1023 


Cell Site ID 



Base ID: Pole Position 

The Pole Position Field consists of 4 bits which are used 
to identify a particular Base Station with the Cell. It is used 
to distinguish between different Base Stations at the same Cell 
Site (e.g., "on the pole"). 



0 


Pole Position ID 


1 








15 





Base ID: TRX Unit 

The TRX Unit Field consists of 2 bits which are used to 
identify a particular TRX Unit within the Base Station. 



30 



35 



Meaning 



0 


Reserved (for 'Either TRX Unit') 


1 


TRX Unit 1 


1 


TRX Unit 2 


3 


Reserved (for 'both TRX Units') 
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For DCS 1900, only values 2 and 2 are meaningful. 
3 are unused. 



PCT/US96/15190 



Values 0 and 



Table 4-15 
Base Status [N,Il 

The Base Status information element shall be comprised of 
32 octets. 



10 



15 



18 



32 octets of Base Status 



Octets 

1 
2 



32 



20 



25 



30 



Table 4-16 

Broadcast ID [O] 
The Broadcast ID information element is used to identify 
specific broadcast data streams. The ID is assigned to the 
specific broadcast stream on a connection basis. It is the 
responsibility of the broadcast Network Application to provide 
periodic application broadcast heading information. The 
Broadcast ID is assigned at the start of a connection and 
released to the Broadcast ID pool at the termination of the 
connection . 



8 



8 bits of Broadcast ID 



Octets 

1 1 
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Table 4-17 
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BS Capabilities lO,M] 
The BS Capabilities information element describes the 
services being offered by the BS . The internal format of this 
element is shown below. 



10 



15 



20 



Base Features 



Base Features 



Base Features 



Access Class 



Leveling Bits 



Octets 

1 
2 
3 
4 



IBS Capabilities: Base Features 

The Base Features subfield is 20 bits in length. These 
bits are used to provide the MS information about the base and 
correspond to various base capabilities or features. Features 
such as ethernet access, aggregate data capability, enhanced 
voice, etc. are selected here. The particular features depend 
upon the networks which the BS supports. 

BS Capabilities: Base Features for DCS1900 Systems 



25 



30 



8 7 6 




5 


4 


3 2 


1 


Octets 




Base 


Features 






1 




Base 


Features 






2 


Base Features 




3 


1 Bit: This 


bit, 


if set to 


1, indicates 


that the BSC 



services 



this BS is capable of Inter-BSC Terminating Handovers 



1 Bit: More Slots (OTA) than Channels (Backhaul) 
All bits not explicitly defined are reserved. 



35 
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BS Capabilities: Access Class 
Integral value from 0 through 15 which designates the 
lowest class allowed access to the base. That is, if the MS 
were provisioned with an access class of 3 , it would be allowed 
to register with base stations that broadcast an access class of 
3 or lower. This subfield is active only if the CU field in the 
Header specifies that Class Control is in effect. 



Value Access Allowed to 



15 


lest rioDi±es onxy 


14 


911 calls only 


13 


Reserved 


12 


Reserved 


11 


Reserved 


10 


Mobiles with Access Class 10 


9 


Mobiles with Access Class 9 or 10 














1 


Mobiles with Access Class 1, 2, ... 10 


0 


All Mobiles 



BS Capabilities: Leveling Bits 

25 8 bits, set by the base station to level out the number of 

mobile stations registering or using a base. A mobile station 
would be allowed to access a base station if the leveling bit of 
the mobile station was set in this field. The leveling bit 
number will be selected by taking the modulo 8 of the MS's 

30 Permanent PID. If the corresponding bit in the base station 
leveling field were set then the MS would be allowed access, 
otherwise, the MS would have to access another BS . This 
subfield is active only if the CU field in the Header specifies 
that Class Control is in effect. 
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Table 4-18 



10 



15 



BS Information [M] 

The BS Information Element is a collection of Information 
Elements which give details associated with a BS . It exists for 
notational convenience because of its frequent occurrence in 
lists . 



Bits 
7 6 



20 



25 



Zone [5 Octets] 



BSC ID [2 Octets] 



Base ID [4 Octets] 



BS Capabilities [4 Octets] 



Octets 



1 
2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 



Table 4-19 



30 



BSC ID [O, M] 



35 



The base station controller identifier, in conjunction 
with the PLMN, uniquely identifies the specific base station 
controller 105. The low order bit of the 16 bit number is 
located in Bit 1 Octet. The high order bit of the 16 bit number 
is located in Bit 8 of Octet 2. 
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Octets 



16 bits of unique BSC identification 



1 
2 



Table 4-20 

Cause [O, M, N, I] 
The Cause information element consists of 8 bits 
10 identifying the cause for, or the result of, a specific action. 
The particular meanings of Cause values are determined by the 
message in which the Cause information element appears. 



15 



Bits 
6 5 



8 bits of Cause information 



Table 4-21.1 



Octets 



20 



25 



30 



Cause: Authentication Reject [N, J] 
CT-RCP [O] 

Registration Result [M, N, J] 
Service Response [M, N, I] 



Value 



Meaning 



0 


Success 


1 


IMS I Unknown in HLR 


2 


Illegal MS 


3 


Illegal ME 


4 


PLMN Not Allowed (i.e., don't try any 
cells with same MCC, MNC) 


5 


LAI Not Allowed (i,e., don't try any 
cells with the same LAI) 


6 


National Roaming Not Allowed in the 

LAI 


7 


Protocol Error 


8 


Network Failure 


9-255 


Reserved 
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Table 4-21.2 



10 



15 



20 



Cause : 


Cipher Response [N, I] 




Value 


Meaning 




0 


No Result 


X 


Success, Cipher 


2 


Success, Clear Mask 


3 


BS Reject 


4 


MS Reject 


5-255 


Reserved 


Table 4-21.3 


Cause: Connect Link [N, I] 




Setup Link [N, I] 




Value 


Meaning 




0 


Link Successful 




1 


Link Failure 




2-255 


Reserved 





25 



Table 4-21.4 Cause: CT-ACK [O] 

Unless specified otherwise below, the Cause 
Information Element in CT-ACK messages always has a value of 



zero , 



Table 4-21.4.1 
Cause: CT-ACK in response to CT-CSC 



30 



0 


Acknowledged 


1 


Circuit Switch Refused 


2-255 


Reserved 
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Table 4-21.5 Cause: CT-CIP [O] 
Value Meaning 



0 


Set or Change Cipher 


1 


Synchronize Cipher 


2-255 


Reserved 



Table 4-21.6 Cause: CT-CNC [O] 
Value Meaning 



0 


The requested connection has been connected 


1 


Unable to complete the requested connection 


2-255 


Reserved 



Table 4-21.7 Cause: CT-DRG [O] 
15 Deregister [M, N, I] 

Value Meaning 



0 


Release by MS 


1-255 


Reserved 



20 

Table 4-21.8 Cause: CT-HOF [O] 
Handover Failed IN, I] 



Value 


Meaning 


0 


Reserved 


1 


Refused by Originating BS 


2 


Refused by Terminating BS 


3 


Refused by Originating BSC 


4 


Refused by Terminating BSC 


5 


THR Failed, OHR Suggested 


6 


Invalid HRef 


7-255 


Reserved 
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Table 4-21.9 Cause: CT-REL [O] 
Release Link \M. N, II 



0 


Release by Network 


1 


Release by MS 


2 


Release by BS (Link Lost) 


3 


Release by BS During Handover 
(e.g.. Circuit Switch Complete) 


4-255 


Reserved 



10 



Table 4-21.10 Cause: CT-SET [O] 

Meaning 



15 



0 


Link Successful 


1 


Link Failed 


2-255 


Reserved 



See Cause: CT-DRG [Ol 
See Cause: CT-HOF [O] 



20 



Table 4-21.11 Cause: Handover Request ACK [N, I] 



25 



Value 


Meaning 


0 


No Result 


1 


Success, Cipher 


2 


Success, Clear Mask 


3 


Fail, No Resources 


4 


Fail, Cipher Algorithm Not Supported 


5-255 


Reserved 



30 



See Cause 
See Cause 



CT-RCP [O] 
CT-REL [O] 



35 



Tcible 4-21.12 Cause: Service Info [O] 

This Cause is unique in that it is divided into two 
subfield to carry results for both the MS and the BS . 
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Bits 
5 



Octets 
2 1 



MS Cause 



BS Cause 



The meanings 



of each subfield are: 



0 


Success 


1 


Failure 


2-15 


Reserved 



see Cause: CT-RCP [O] 

See Cause: Connect Link [N, I] 



Table 4-21.13 cause: Specific Poll Result [O] 



Value 


Meaning 


0 


No Result 


1 


Specific poll for PID 


2 


General poll response from PID is rejected 


3 


Page to MS 


4-256 


Reserved 



Cause: DCS1900 Systems 

For DCS1900, the mapping of GSM Causes to Omnipoint Causes 
is given in the following tables. This translation is for CT- 
RCP, CT-SRS, Register_Cnf , Registration Result, Service 
Response . 



Omnipoint 
Value 



0_ 
2 



GSM 
Va^e 

0 



3 8/27/1996 



Meaning 



Success 



IMS I unknovm in HLR 



Illegal MS 



I MS I unknown in VLR 



IMEI not accepted 
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10 



15 





6 


1 Illegal ME 


_5 


11 


1 PLMN not allowed 


A 


1 LAI not allowed 


4 


13 


National Roaming not 
Allowed In this LAI 


5 


17 


1 Network Failure 


5 


22 


1 Congestion 


6 


32 


Service option not 
[supported 


6 


33 


Requested service option 
Jnot subscribed 


6 


34 


Iservice option temporarily 
put of order 


6 


38 


1 Call cannot be identified 




95 


1 Semantically incorrect 
Jnessage 


6 


96 


Invalid mandatory 
{information 


6 


97 


Message type non-existent 
[not implemented 


6 


98 


Message nou compctuxuxc 
protocol state 


6 


99 


tLnformation element non- 
jsxistent or not implemented 


6 


100 


1 Conditional IE error 


6 


101 


[Message not compatible with 
1 protocol state 


6 


111 


iProtocol error, unspecified 



20 



Table 4-22 

Channel Preference IM.N.I) 

The Channel Preference information element indicates the 
sender's preference for which channel --B or D--is used over the 
O Interface to transport the data contained in the message. 



25 



3NSDOCID: <WO 97133S3A1.I.» 



wo 97/13353 

88 

87654321 
8 bit Channel Preference 



Value 


Meaning 


0 


B Channel Preempt : Use existing 
circuit; do not attempt to acquire 
Separate Signaling Slot. 


1 


B Channel Required: Importance 
relatively high: use Separate 
Signaling Slot if available, otherwise 
preempt B Channel. 


2 


B Channel Preferred: Moderate 
Importance: use Separate Signaling 
Slot if available, otherwise use 
D Channel 


3 


D Channel Preferred: Importance 
relatively low; use D Channel if B 
Channel is not available. 


4-255 


Reserved 



There is no purpose to having a D Channel Required value 
it would only be useful in the case where the B Channel was 
available and the application wanted the OTA to use the D 
Channel anyway. Such a request would be ignored byte OTA to 
conserve bandwidth (pushing a Transport Note through the D 
Channel at a rate of one byte per frame while wasting the 19 
bytes available in the B channel it could take up to 5 
seconds to get the Transport Note through this way -- is just 
too wasteful of resources) . 

Chaxmel Preference: DCS1900 Systems 
For DCS1900 Systems, the following mapping will suffice- - 
more sophisticated mapping would probably select some messages 
with TCID 0 which could be assigned a preference of D Channel 
Preferred, E.g., Start/Stop DTMF, Advice of Charge, etc.: 



PCT/US96/I5B90 

Octets 
1 
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10 



TCID 


Channel 
Preference 


Comments 


0 


1 


B Channel required for CC, 
MM and SS Transport 


3 


3 


D Channel preferred for SMS 
Transport 



Table 4-23 
Channel Rate 

The Channel Rate information element appears both as a 4- 
bit field in the Resource Request Data information element and 
as a 1-octet information element in other messages. Only values 
0-15 are legal, all higher values are illegal since they will 
not fit in 4 bits. Only values 0-6 have been defined; the 
remaining 8 values will be defined when needed from the 
remaining 14 candidate Channel Rates. 



15 



Reserved 



4 bit Channel Rate 



Octets 
1 





Value 


Channel Rate 
in Slots/Frame 


Equivalent Raw 
Data Rate 
(bits /second) 


20 


0 


1/32 


300 




1 


1/16 


600 




2 


1/8 


1, 200 




3 


1/4 


2,400 




4 




4 , 800 


25 


5 


1/1 


9, 600 




6 


2/1 


19,200 




7-15 


Reserved 






Candidate 


3/1 


28,800 




Candidate 


4/1 


38,400 


30 


Candidate 


5/1 


48, 000 




Candidate 


6/1 


57 , 600 
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5 



Candidate 


7/1 


6 7, 200 


Candidate 


8/1 


7 6 8 on 


Candidate 


9/1 


R 4 n n 


Candidate 


10/1 


96 ,000 


Candidate 


11/1 


105.600 


Candidate 


12/1 


115 200 


Candidate 


13/1 


124 .800 


Candidate 


14/1 


134 ,400 


Candidate 


15/1 


144 , 000 


Candidate 


16/1 


153 , 600 


Candidate 


Illegal 


Not Applicable 



Channel Rate: DCS1900 Systems 
15 For DCS1900 Initial Deployment, only value 5 (1 slot /frame) 

is supported. In the future, when aggregated data is supported, 
the other values will be supported as well. 

Table 4-24 

20 CI (Correlative ID) [0,H,I] 

The CI (Correlative ID) is a single octet which serves as a 
short -hand identifier (nickname) for an active MS. Cls are 
managed by the BS and are (currently) guaranteed to uniquely 
identify an active MS during a session. AN MS. will be assigned 
25 a new (probably different) CI at the beginning of each session. 

87654321 Octets 



8 bits of correlative ID 



Notes passed over the N and I interfaces generally contain 
3 0 a PID which the BS OTA must use to associate the Note with the 
particular OTA link. Since the PID is nine bytes in length, 
this can potentially be a compute intensive process. To 
simplify the BS's task of mapping a Note to a particular slot, 
the CI shall be included in each RMT Note which contains a PID 
35 in both directions over the O and I interfaces. Notes which do 
not contain a PID do not include a CI . 
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The CI occupies the D Channel on all 0_Not:es except CT-GPO 
(General Poll) and possibly CT-GPR (General Poll Response) . It 
is used by the MS to identify 0_Notes meant for it. This allows 
the MS to recover from an error during Fast Control Traffic. 
5 The management of Cls will be according to the following rules: 

• The BS will assign a unique CI to each mobile during 
slot acquisition. The BS will use a FIFO queue to 
manage Cls to spread Cl usage over the entire legal 
range and insure a maximal delay between reuse of a 

10 given Cl . Legal Cl values are 1 to 255. 

• The BS will include the Cl in each Notes_RMT message 
to the BSC (in those messages which contain a PID) . 

• The BSC will retain the Cl and return it to the BS in 
all messages containing the same PID (i.e., the PID 

15 received with the Cl from the BS) , The BSC must 

always save and use the most recent value of the Cl 
received from the BS , 
In future, there is a possibility that the Cl may change in 
middle of session (upon entry/exit from Slow Control Traffic) . 
20 This will only occur if at some future date there is a 

requirement to simultaneously support a total of more than 255 
active mobiles. In theory it is possible to have 15 slots all 
fully occupied with mobiles communicating once every 25 f rames . 
This is the worst case and will probably never happen, but is 
25 provides a theoretical maximum of 15 * 25 = 375 active Mobiles 
at any one time. Since this exceeds the 255 maximum Cl limit, 
we must make provision for separate numbering of mobiles in slow 
control traffic and would need to deassign/reassign Cls on the 
entry/exit of Slow Control Traffic mode. The implication that 
30 this has on the current design is imply that the Cl may not be 
guaranteed unique over the entire session for a given mobile. 
In addition to the requirement (above) that the BSC always save 
and use the most recent value of the Cl received from the BS , it 
imposes the following additional limitations on the use of Cls 
35 as handles to information concerning the MS: 

• If the BSC uses the Cl as a handle which it may as 
an implementation option it must verify that the 
• PID in the data record found matches the PID which 
accompanied the Cl in the Note. If the two PIDs do 
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15 
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not match, the BSC must ignore the CI and use the PID 
in the note to identify the appropriate data record. 
This insulates the BSC programming from having to 
change if Cls ever cease to be unique. 

If the BS ever manages Cls in a fashion that does not 
guarantee their uniqueness, the BS also must verify 
that the PID in the date record found matches the PID 
which accompanied the Cl in the Note. if the two PIDs 
do not match, the BS must ignore the Cl and use the 
PID in the Note to identify the appropriate data 
record. 

The MS must also use the most recent Cl it receives 
from the BS in a Specific Poll - -CT-SPO- -which contains 
its PID. 

Table 4-25 Cipher Algorithm ID [N, I] 



20 



The Cipher Algorithm ID specifies that algorithm to be 
used for ciphering. 

Bits Octets 
8 7 6 5 4 3 2 1 



25 



8 bits of Algorithm ID 



30 



Algorithm ID 


0 


Transparent ( Clear ) 


1 


A5/1 Algorithm 


2 


A5/2 Algorithm 


3 


A5/3 Algorithm 


4-255 


Reserved 



Table 4-26 Cipher Key [W, I] 



35 The Cipher Key information element contains the clear 

text key to be used to set the key of the BS's encryption 
equipment . 
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Bits 
6 5 4 



PCT/US96/15I90 



Octets 



64 bit Clear Text Cipher Key 



1 
2 



Table 4-27 Cipher Key Sequence # [O, M, N, I] 

The Key Sequence # information element is used to 
select a cipher key in both the BS and MS without having to 
explicitly pass the key over the air. The Key Sequence # will 
be generated as defined in <TBD> . Not all bits of the key 
sequence # may be significant. 



8 



Bits 
5 



Octets 



8 bit Key Sequence # 



Bits 5-8: Must be zero 
Bits 1-4: Are Significant 

Default is ^OFx' in there is no Cipher , Key Sequence # 



Table 4-28 Class [O, N, I] 



30 



35 



The Class information element specifies some of the 
operational parameters of the particular typ of MS being used 



Bits 



Octets 



8 7 


6 


5 4 3 2 1 


Class 


Type 


Class Information 


Class Information 



1 

2 
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Class Type 



0 


Reserved 


1 


DCS1900 Class Type 


2 


IS-41 Class Type 


3-7 


Reserved 



Table 4-28.1 Class Information for DCS1900 Class Type 

Bits Octets 



8 


7 


6 




5 


4 3' 


2 


1 


Not Available 


Rese 
rved 


Revision 
Level 


A5/1 


A5/2 


A5/3 


SM 


SS 


Screen 
Ind. 


Reserved 



Revision Level 



0 


PCS2000 phase 1 Mobiles 


1-3 


Reserved 



A5/1 



0 


A5/1 encryption algorithm not available 


1 


A5/1 encryption algorithm is available 



AS/ [2 I 3] 



0 


A5/[2|3] encryption algorithm is 
available 


1 


A5/[2|3] encryption algorithm is not 
available 



SM 



0 


short message capability not present 


1 


short message capability present 
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SS Screen 
Indicator 



5 



0 


GSM phase 1 


1 


capable of handling ellipsis notation 
and phase 2 error handling 


2-3 


reserved 



Table 4-28.2 Class Information for IS-41 Class Type 



Bits ' Octets 



10 



Not Available 


Reserved 


H 1 G 


F 


E 


D 


C 


B 1 A 



Power Class (PCP) (octet 1, bits A, B and E) 

Bits H G F E D C B A Value Meaning 



20 











0 






0 


0 




Class I 










0 






0 


1 




Class II 










0 






1 


0 




Class III 










0 






1 


1 




Class IV 










1 






0 


0 




Class V 










1 






0 


1 




Class VI 










1 






1 


0 




Class VII 










1 






1 


1 




Class VIII 



25 

Transmission (TX) (octet 1, bit C) 



H G F E D C B A Value Meaning 



30 















0 








Continuous 














1 








Discontinuous 



Bandwidth (BW) (octet 1, bit D) 



35 



Bits 


H 


G 


F 


E 


D 


C 


B 


A 


Value 


Meaning 












0 










20 MHZ 












1 










2 5 MHZ 



BNSDOCID; <WO 97133S3A1.) _> 



wo 97/13353 



PCT/US96/15190 



96 



Table 4-28.2.1 Mobile Station Nominal Power Levels 



10 



15 



Mobile 
Station 
Power Level 

(PL) 



Mobile 
Attenuation 
Code 

(MAC) 



Nominal ERP (dBVJ) for 
Mobile Station Power 
Class 



0000 



0001 



0010 



0011 



0100 



0101 



0110 



0111 



I 
I 
I 



I 
V 



V 



V 

I 



1 1 



V 

I 
I 
I 



Dual Mode Only_ 
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8 


1000 


2 
2 


2 
2 


2 
2 


2 
6 
+ 
/ 

3 
a 
B 


★ 


* 


* 






1001 










★ 






* 






2 


2 


2 


3 














2 


2 


2 


0 




















+ 




















/ 




















6 




















d 




















B 










10 


1010 


2 
2 


2 
2 


2 
2 


3 
4 
+ 
/ 

9 
d 
B 


★ 


•k 


•*■ 


* 



The three lease significant bits of MAC are used in 
the Cl^C/VMAC field. All four bits of MAC are used in the DMAC 
field. 



20 Table 4-29 Connection Number [O, M, N, I] 

The Connection Number information element specifies 
the specific network connection which was allocated to carrying 
the bearer channel of this user station 102 from the base 
station 104 to the network. All octets of this information 
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element may not be significant. Unused nibbles and octets must 
be filled with "F" hex. 

The Connection Number in conjunction with the Zone and 
the base station controller ID uniquely identify every possible 
connection in the world. 



Bits 

5 



24 bis of Connection Number 



Table 4-30 



Octets 

1 
2 
3 



15 



Connection Result [M] 



D Channel [Ol 

The D Channel information element transmits the out of band 
application channel in a byte serial manner. It is available 
20 for this use only when bearer data is being transmitted (i.e., 

when the Packet Type field in the 0_Note Header has a value of O 
(Normal Traffic) . During signaling (all other Packet Types) it 
is used for the CI (or other special purposes) . 
ESN [0,M,N,I] 

25 The equipment serial number uniquely identifies the MS. 



30 



64 bits of ESN 

O 
O 

o 



1 Octets 



1 
2 



35 



FCW [O] 
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99 



The Frame Check Word, which checks the content of a packet 
information element, shall be a 16 bit sequence. It shall be 
the ones complement of the sum (modulo 2) of: 

a) The remainder of 

x*' (x'''+x'Vx'^+x^^+x''+x'°+x^+x' + xVx'+x^^^xVx^+x^+x' + l) 
divided (modulo 2) by the generator polynomial 
x^^+x^^+x^+1 , where k is the number of bits in the 
packet not including the FCW. 

b) The remainder of the division (modulo 2) by the 
generator polynomial x^^+x'^+x^+1 of the product of x'^ 
by the content of the packet existing from and 
including the first bit of the packet to but not 
including the first bit of the FCW . 



15 



8 



Bits 
5 4 



16 bits of FCW 



Octets 

1 

2 



20 



Table 4-31 Correlative ID [O] 



25 



30 



The Correlative information element is used to 
temporarily identify a group of frames as being destined to a 
specific user station 102. The ID is assigned for the duration 
of the connection and is released for reuse by another user 
station 102 at the termination of a connection. The specific 
value of " OFFx" is reserved for broadcast use. The correlative 
ID for a specific user station 102 will not be changed during a 
connection . 



35 



Bits 
5 4 



8 bits of correlative ID 



Octets 
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Table 4*32 Count Base [N, I] 

The Count Base information element is used to specify 
the number of sets of base information which follow in the Notes. 
5 RMT Originating Handover message. Each set of base information 
consists of three information elements: Zone, base station 
controller (BSC) ID and Base ID, 

Bits Octets 
10 8 7 6 5 4 3 2 1 



8 bits of Count Base 



15 



20 



Table 4-33 D Channel [O] 

The D Channel information element transmits the out of band 
application channel in a byte serial manner. The data is 
transmitted with the low order bit of the D channel information 
in Bit 1 of the Octet. 

Table 4-34 ESN [O, n, N, I] 



25 



30 



The equipment serial number uniquely identifies the 
user station 102 . 



Bits 
6 5 4 



3 2 1 



64 bits of ESN 



Octets 

1 
2 



35 
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Table 4-35 Facility [O, M] 



PCT/US96/15190 



The Facility information element describes the 
services being offered by the base station 104. The internal 
format of this element is shown below. 



10 



15 



20 



Bits 
6 5 



Octets 



Base Features 



Base Features 



Base Features 



Access Class 



Leveling Bits 



1 
2 
3 
4 



The Base Features subfield is 20 bits in length. 
These bits are used to provide the user station 102 information 
about the base station 104 and correspond to various base 
station capabilities or features. Features such as ethernet 
access, aggregate data capability, enhanced voice, etc. are 
selected here. The particular features depend upon the networks 
which the base station 104 supports. 

Table 4-35.1 Base Features for DCS1900 Systems 



25 



30 





Bits 




Octets 


8 7 


6 5 


4 3 


2 1 




Base Features 


1 


Base Features 


2 


Base 


Features 




3 


1 Bit : 


This bit, if 


set to 1 , 


indicates 


that this 



base station 104 is capable of Inter-BSC Terminating Handovers 
All bits not explicitly defined are reserved. 



35 



Table 4-35.2 Facilities: Access Class 

Integral value from 0 through 15 which designates the 
lowest class allowed access to the base station 104. That is, 
if the user station 1021 were provisioned with an access class 
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of 3, it would be allowed to register with base stations 104 
that broadcast an access class of 3 or lower. This subfield is 
active only if the CU field in the Header specifies that Class 
Control is in effect. 



Value 



Access Allowed to 



10 



15 


Test Mobiles only 


14 


911 calls only 


13 


Reserved 


12 


Reserved 


11 


Reserved 


10 


Mobiles with Access Class 10 


9 


Mobiles with Access Class 9 or 10 







15 







1 


Mobiles with Access Class 1, 2, ... 10 


0 


All Mobiles 



20 8 bits, set by the base station to level out the 

number of user stations 102 registering or using a base station 
104 . A user station 102 would be allowed to access a base 
station 104 if the leveling bit of the user station 102 was set 
in this field. The leveling bit number will' be selected by 

25 taking the modulo 15 of the user station PID. If the 

corresponding bit in the base station 104 leveling field were 
set then the user station 102 would be allowed access , 
otherwise , the user station 102 would have to access another 
base station 104. This subfield is active only if the CU field 

30 in the Header specifies that Class Control is in effect. 



Table 4-3 6 FCW [O] 
The Frame Check Word, which checks the content of a packet 
information element , is be a 16 bit sequence . It comprises the 
35 ones complement of the sum (modulo 2) of: 
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10 



a) 



b) 



The remainder of 

,k,,15,,14,^13.,12.,ll.,10.,9.,8.,7.,6.,5.,4,,3.,2.,l,,, 
divided (modulo 2) by the generator polynomial 



,16 



+x^^+x^ + l, where k is the number of bits in the 



packet not including the FCW . 

The remainder of the division (modulo 2) by the 
generator polynomial x'^+x^^+x^ + 1 of the product of x 
by the content of the packet existing from and 
including the first bit of the packet to but not 
including the first bit of the FCW. 



16 



15 



Bits 
5 



16 bits of FCW 



Octets 



1 

2 



20 



Table 4-37 Frame Number [O] 

The Frame Number information element is used in ciphering 
algorithms. Each base station 104 keeps its frame number as a 
count of the number of frames it has traversed since power up. 



25 



Bits 
6 5 



Octets 



22 bits of Frame Number 



1 
2 
3 



30 



Taible 4-38 Follow On Proceed lO,M,N,I] 
The Follow On Proceed information element contains a single 

bit of information: either another Network Level Service Request 

is allowed or it is not. 

This information element also appears as a 1 bit field in 

the Registration Result information element. 



35 
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104 



Bits 
6 5 



8 bits of Follow On Proceed Information 



Follow On Proceed: DCS1900 Systems 
For DCS1900, the values are: 



PCT/US96/1 51190 



Octets 



Value 


Meaning 


0 


Follow On Proceed Not Allowed 


1 


Follow On Proceed 


2-255 


Illegal 



15 



20 



25 



30 



Table 4-3 9 Frame Offset [O] 

The Frame Offset information element is the number of slots 
between the current slot and the beginning of the next frame. 
This tells the MS when the next frame begins, so it may 
increment the Frame Number synchronously with the BS while 
encrypting. This is required to support aggregated data and 
timeslot interchange in cipher mode. 

The Frame Offset always reflects the correct value for the 
slot in which the CT message containing the Frame Offset 
information element is transmitted and received without error. 
This means that the sender must recompute the Frame Offset 
whenever it needs to re -send the CT message. 



Bits 
6 5 



Octets 



8 bits of Frame Offset 



Table 4-40 HRef (Handover Reference) 
The HRef (Handover Reference) information element is 
used to identify a specific handover process that has already 
been initiated by an Originating Handover Request sequence. 
Not all bits are significant. 
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Bits 



PCT/US96/15190 

Octets 



10 



15 



20 



25 



30 



48 bits of HRef (Handover Reference) 



1 
2 
3 
4 
5 
6 



Table 4-4 0.1 HRef for DCS1900 Systems 

In a DCS1900 infrastructure system, the HRef is 
assigned by the terminating Base Station Controller. Only one 
octet is significant. 



Bits 
5 4 3 



8 bits of HRef (Handover Reference) 



Reserved 



Octets 

1 
2 
3 
4 
5 
6 



Table 4-41 Identity Data [O, N, I] 
The Identity Data information element contains one of 
the identifiers of the MS as specified by the associated 
Identity Type. The precise length and format of the Identity 
Data information element will be determined by the Identity 
Type. If the length is less than the maximum 9 octets provided 
for the Identity Data information element, unused space will be 
at the end of the Identity Data information element (Octets 9, 
8, ...) and all unused bits will be set to zero. 



35 
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30 
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Bits 
5 



Octets 
2 1 



72 bits of Identity Element 



1 
2 
3 
4 
5 
6 
7 
8 
9 



Tcible 4-42 Identity Type [O, N, I] 

The Identity Type information element specifies which 
identity is being requested or supplied. 



Bits 
5 4 3 



Octets 



8 bits of Identity Type 



value 


Identity Type 


0 


IMSI 


1 


TMSI 


2 


ESN 


3 


UPT# 


4-255 


Reserved 



Table 4-34 LAC (Location Area Code) 

See Zone . 

Table 4-35 LAI (Location Area Identifier) 



35 



See Zone . 
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Table 4-43 Location [N, I] 

The Location information element provides the 
identification of a specific element in the given table, 
actual element identifiers are table dependent. 

Bits Octets 



The 



8 



10 



15 



20 



25 



16 bits of Location Identifier 



1 
2 



Table 4-44 MCC 
MCC (Mobile Country Code) 
The MCC (Mobile Country Code) identifies the County in 
which the network exists. In combination with the MNC it forms 
the PLMN and uniquely identifies a given network operator. It 
never appears as an independent information element in any Note 

Bits Octets 
87654321 



16 bits of Mobility Country Code 



1 
2 



Table 4-45 Message Length [M, N, I] 

The Message Length field is to be filled in with the 
size of the message including the size field 
itself. The length of the message is measured in octets. 

Bits Octets 

8 7 6 5 4 3 2 1 



8 bits of Message Length 



• 30 Table 4-46 Message Type [O, M, N, I] 

The Message Type information element defines the 
format of the rest of the message. The interpretation of the 
Message Type depends upon which particular Notes protocol is 
being discussed. Currently, the messages are sorted in 
35 alphabetical order by name. An effort is made, where possible, 
to maintain the same Message Type across all interfaces for 
common messages (e.g.. Set Link). 
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Bits 
5 



Octets 



8 bits of Message Type 



Table 4-47.1 O Notes Message Type [O] 



10 



15 



20 



25 



30 



35 



Bits 1-8 (Hex) 


Type 


00 


Reserved 


01 


ACK- Acknowledge 


02 


AUR-Auth'entication Response 


03 


AUT-Authentication Request 


04 


BAI-Base Assist Information 


05 


BAR-Base Assist Request 


06 


CIP-Set Cipher Mode 


07 


CNC-Call Connected 


08 


CNL- Connect Link 


09 


CSC-Circuit Switch Complete 


OA 


DRG-De-registration Request 


OB 


HLD-Hold 


OC 


HOF-Handover Failed 


OD 


MAI -MS Assist Information 


OE 


MAR-MS Assist Request 


OF 


OHC-Originating Handover Complete 


10 


OHR-Originating Handover Request 


11 


ORG-Originate Call 


12 


RCP-Registration Complete 


13 


REL-Release Link 


14 


RRQ-Registration Request 


15 


SPR- Specif ic Response 


16 


STL- Set Link 


17 


S YN - Synchr oni z e 


18 


XHC-Terminating Handover Complete 


19 


THR-Target Handover Request 


1A-7F 


Reserved 


80-FF 


TRA-Transport Message w, TCID 
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If the most significant bit of the Message Type is set 
to 1, the message is a Transport Message. The seven least 
significant bits are used to specify the Transport Channel ID 
with which the data is associated. 



Bits 
S 



Octets 



TCID 



10 



Table 4-47,2 M Notes Message Type [M] 



The Message Type information element defines the 
format for the remainder of the M Notes message. 



15 



20 



25 



30 



Value (Hex) 


Description 


01 


Diagnostic 


02 


Initialize OTA 


03 


Register 


04 


Deregister 


05 


Setup Link 


06 


Release Link 


07 


Connect Link 


08 


Acknowledge 


09 


Provision OTA 


OA 


Radio Status 


OB 


Link Status 


OC 


Data Message 


OD 


Power Off 


OE 


Circuit Switch Complete 


OF 


Begin Traffic 


10 


Acknowl edge 


11 


Authenticate 


12 


Authenticate Reply 



35 
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Table 4-47.3 N Notes Message Type [N, I] 

This Message Type information element defines the use 
of O-Notes and I-Notes. It defines the action of the message as 
well as the format of the message. 



10 



15 



20 



25 



30 



35 



Type (Hex) 


Meaning 


00 


Reserved 


01 


Acknowledge 


02 


Authenticate 


03 


Authenticate Reply 


04 


Base Status Request 


05 


Base Status Response 


06 


Cipher ACK 


07 


Circuit Switch Complete 


08 


Connect Link 


09 


Deregister 


OA 


DTMF Start 


OB 


DTMF Stop 


OC 


Originating Handover 


OD 


Page 


OE 


Page Response 


OF 


Register 


10 


Registration Reject 


11 


Service Information 


12 


Set Cipher Mode 


13 


Set Link 


14 


Terminating Handover 


15 


Terminating Handover Complete 


16 


Transport 


17 


Update ID 


18-7F 


Reserved for Notes RMT 


80 


Diagnostic 


81 


Diagnostic Result 


82 


Download 
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10 



15 



20 



83 


Provision Table 


84 


Read Table 


85 


Reject 


86 


Reset 


87 


Reset ACK 


88 


Table Data 


89-FF 


Reserved for Notes_OAM 



Transport Message Types 

If the most significant bit of the Message Type is set to 
1, the message is a Transport Message. The 7 least significant 
bits are used to specify the Transport Channel ID with which the 
data is associated. 



8 



TCID 



1 Octets 
1 



25 



MNC (Mobile Network Code) 

The MCC (Mobile Network Code) identifies the network within 
the country in which the network exists. In combination with 
the MCC if forms the PLMN and uniquely identifies a given 
network operator. It never appears as an independent 
information element in any Note. Test 



8 



8 bits of Mobile Network Code 



1 Octets 
1 



30 



35 



Table 4-48 MS Capabilities [O] 

The MS Capabilities information element defines the 
capabilities (features) present in the user station 102 (e.g. 
whether the user station 102 can receive a FAX or a data 
connection, whether the user station 102 is capable of 
ciphering, etc.) . 
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25 
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Bits Octets 
87654321 



16 bits of MS Capabilities 



1 
2 



Network Periodic Control [M] 

The Network Periodic Control information element specifies 
whether the MS OTA should perform automatic periodic network 
registration . 



8 



8 bits of Network Periodic Control 



Octets 
1 



Value 
(Hex) 


Description 


GO 


OTA should NOT perform network periodic 
registration 


01 


OTA should perform network periodic 
registration 


02-FF 


Reserved 



Network Service Request Data [0,M,N,I] 



16 octets of Network Specific Service Request Data 



Octets 

1 
2 



24 



Network Service Request Data for DCS1900 Systems 
For DCS1900, this is the CM Service Request. 



35 
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Network Service Response [0,M,N,I] 



PCT/US96/I5190 




Octets 

1 
2 
3 



10 



15 



20 



Network Service Response for DCS1900 Systems 

For DCS1900, this is the CM Service Accept (octets in first two 
octets of the element) or the CM Service Reject (3 octets) . 

Table 4-49 OTA Map [O] 

The OTA Map information element describes the mapping 
of the OTA time slots to a particular user station 102. The 
format of this element is dependent upon the OTA Map Type 
information element in the same packet. 

Table 4-50.1 Superframe Map: 



25 



Bits 
5 4 3 



16 bits of slot mapping description 



16 bits reserved 



Octets 

1 
2 
3 
4 



30 



35 



Each bit in the superframe map indicates a time slot 
relative to the current time slot. 



Octet 
1 
1 
1 
2 



Bit Time slot 

1 Same time slot, next frame 

2 This frame, one time slot later 

3 This frame, two time slots later 
8 This frame, 15 time slots later 
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Table 4-50.2 Sxibframe Map: 
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Bits 


8 7 6 


S 4 3 2 1 


Reserved 


Submultiplex 


Reserved 


Frame Phase 


Reserved 


Time lot Phase 


Reserved 



Octets 

1 
2 
3 
4 



10 



Submultiplex Rate 
(Subrate) 

Frame Phase 



Time slot Phase 



The number of frames 
skipped between 
transmissions, plus one. 

The number of frames 
skipped before the first 

transmission . 
The number of time slots 
skipped before the first 
transmission , 



15 



20 



25 



As an example, where the subrate is four, the frame 
phase is three, and the time slot phase is two, the user station 
102 will wait three time frames 301 and two time slots 302 
before the first transmission. Subsequent transmissions will 
occur in the same time slot 302 every fourth time frame 301. 

Table 4-51 OTA Map Type [O] 
The OTA Map Type information element identifies the type of 
OTA Map to follow. 

Bits Octets 
8 7 6 5 4 3 2 1 



8 bits of OTA Map type 



30 
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OTA Map Type 


Meaning 


0 


Unused 


1 


Superf rame 


2 


Subf rame 


3-256 


Reserved 



Page Group Activity [O] 
The Page Group Activity information element indicates, in 
each paging roll, which of the 8 Page Groups - one corresponding 
to each bit in the information element are currently active, 
i.e., have an active page for at least one member MS of the page 
group. The BS and MS determine which Page Group a particular MS 
belongs to using the same algorithm used for the Leveling Bits 
field in the BS Capabilities Information element. 

Bits Octets 
5 4 3 2 1 

4 



8 



Page Group Activity Bits 



Paging/Broadcast Countdown [O] 

The Paging/Broadcast Countdown information element will 
appear in the D Channel of all CT-GPO (General Poll) messages. 
It will indicate the time, in frames, until the next Frame in 
which a Paging Cycle or a Broadcast Cycle will start. The high 
order bit might be used to distinguish between a Paging 
Countdown and a Broadcast Countdown if such distinction proves 
desirable. Since this feature has not yet been implemented, 
this field will always contain 0-which is basically the same as 
" now . " 



30 



Bits 



Octets 



Paging/Broadcast Countdown 



35 



PID [0,M,N,I1 



3NSDOCID: <WO 9713353A 1_t_> 



wo 97/13353 



PCT/US96/15190 



10 



116 

Table 4-52 PID [O, M, N, I] 

This information element is the personal identification number 
assigned to this user station 102. The low order byte defines the 
PID Type. The identifier is represented by the following 64 bits. 
The low order bit of the 64 bit number resides in Bit 1 of Octet 2 
while the high order bit of the 64 bit number resides in Bit 8 of 
Octet 9. 

If the PID Type is absolute, the PID absolutely and 
uniquely identifies the user station 102. The number is 72 bits 
long . 



15 



20 



Bits 
6 5 



Octets 



PID Type 



64 bits of MS identification number 



Table 4-53.1 PID Type 



1 
2 



25 



30 



PID Type 


Meaning 


0 


None 


1 


Permanent PID 


2 


Temporary PID 


3 


ESN 


4 


UPT# 


5 


HRef 


6-255 


Reserved 



35 



In DCS1900 Systems, the Permanent PID associated with a 
user station 102 is the IMSI . 

In DCS1900 Systems, the Temporary PID associated with a 
user station 102 MS is its TMSI . 
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In DCS1900 Systems, the ESN associated with an user 
station 102 is its IMEI . 

A PID of Type=HRef occurs in only limited cases; 

1. In a Specific Poll for the user station 102 from the 
(New) base station 104 during an Originating 
Handover . 

2. In a Release Link (in either direction) during an 
Originating Handover (if the Originating Handover 
fails) . 

A number which uniquely within the PID Type -- 
identifies the user station 102. 



15 



Table 4-54 PLMN {Public Land Mobile Network) 

PLMN (Public Land Mobile Network 
The PLMN (Public Land Mobile Network) uniquely identifies the 
operator of the network. It consists of the MCC and MNC . The PLMN 
occupies the first three Octets of the Zone Information Element; it 
never appears as a distinct information element in any Note. 



20 



25 



Bits 
5 4 



16 bits of unique MCC 



8 bits of unique MNC 



Octets 

1 
2 
3 



Poll Type [O, M] 



30 



The Poll Type information element identifies the reason that 
the Poll was issued. 



35 
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Value Meaning 



5 



0 


Specific poll during Link 
Establishment 


1 


Specific Poll during Handover 


2 


Specific Poll during Lost Link 
Recovery 


3 


Transaction Acknowledged 


4 


Page Pending 


5 


Cl Reassignment 


6-255 


Reserved 



10 Transaction Acknowledged is a special case of a Specific Poll 

during Link Establishment. It tells the MS that the transaction 
requested by the Transaction Hint in the CT-GPR is complete and 
that there is no need for further communication. 

Page Pending is the only Poll Type allowed for a CT-PRO. It 

15 can also appear in a CT-SPO if there is a Page Pending when one of 
the other Poll Types would normally have been sent. 



Table 4-55 Protocol [N, I] 
The protocol information element identifies the signaling 



20 



protocol 



Bits 
6 5 



Octets 



Protocol Identifier 



25 



Protocol Type 



Protocol 



30 



1 


Notes RMT signaling protocol 


2 


Notes OAM signaling protocol 


3-255 


Reserved 
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Table 4-56 Registration Info [O] 
Registration Info contains information that is required by the 
System for registration. The precise format of the Registration 
Info depends upon the value of System Type. 



10 



15 



20 



25 



Bits 
6 5 



Octets 



128 bits of Registration Info 



1 
2 
3 
4 
5 
6 
7 
8 
9 

10 
11 
12 
13 
14 
15 
16 
17 



30 



Table 4-56.1 DCS1900 Systems 

For DCS1900 Systems, the Zone of the base station 104 on 
which the user station 102 was previously registered must be 
provided so the network 126 can locate the appropriate VLR for TMSI 
validation . 
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Bits 
6 5 



10 



15 



20 



40 bits (Old) Zone 



88 bits 



Reserved 



PCT/US96/1 51190 
Octets 

1 
2 
3 
4 
5 
6 
7 
8 
9 

10 
11 
12 
13 
14 
15 
16 
17 



Tadile 4-56.2 Bellcore Generic C Systems 
For Bellcore Generic C Systems, the required registration 
information consists of the user station's UPT# and ESN. 

Bits Octets 



25 



8 



30 



64 bits of ESN 



1 
2 
3 
4 
5 
6 
7 
8 
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64 bits reserved 



9 

10 
11 
12 
13 
14 
15 
16 
17 



Table 4-57 Registration Status [O, M] 



15 



The Registration Status identifies the user station's 
current registration status. 



Octets 



20 




Page Pend : 

value meaning 



0 


There is no page pending 


1 


There is a page pending (only valid in 

CT-RCP) 



Registration Status : 



value status 



0 


Not Registered 


1 


Accepted 


2 


Pending 


3-127 


<TBD> 
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Table 4-58 Registration Timer [O] 



The Registration Timer information element sets the 
intervals between periodic re-registrations. 



Bits 

8 7 6 5 4 3 2 



Octets 



Network Interval 



Base Interval 



10 



Table 4-58.1 Registration Timer: Base Interval 



Value 


Interval 


0 




1 




2 




3 




4 




5 




6 




7 




8 




9 




A 




B 




C 




D 




E 




F 
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Registration Timer: Base Interval 



10 



15 



Value 


Interval 


0 




1 




2 




3 




4 




5 




6 




7 




8 




9 




A 




B 




C 




D 




E 




F 





20 



Table 4-59 Registration Type [O, N, I] 

The Registration TyP^ identifies the type of 
25 registration. Registration is the result of either a position 
change (geographic) or the expiration of the registration timer 
(periodic) . 

Bits Octets 



8 



30 



Registration Type 
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Registration Type: 



5 



value 


type 


0 


Base Geographic Registration 


1 


Network Geographic Registration 


2 


Base Periodic Reregistration 


3 


Network Periodic Reregistration 


4 


Power Up 


5 


Request SBT 


6-255 


Reserved 



Table 4-60 Remaining Base Count [O] 
The Remaining Base Count specifies the number of base stations 
104 in addition to the current one (the one specified in the CT-OHR 
15 message containing the Information Element) for which the user 
station 102 intends to request an Originating Handover at this 
time . 

Bits Octets 



20 



8 



Remaining Base Count 



Table 4-61 Reserved [O, M, I] 
The Reserved information element represents unused space. All 
25 unused space is reserved for future use. All Reserved bits shall 
be set to zero by the transmitting station. All Reserved bits 
shall be ignored by the receiving station unless specifically 
defined otherwise. 

Some Information Elements contain Reserved subfields. 
3 0 The same comments about reserved bits apply. 

Table 4-62 Resource Request Data [O, M, N, I] 
This 32 bit information element specifies the type of service 
being requested by the user station 102. 

35 
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Octets 



8 


7 


6 5 


4 3 


2 1 




DVS 


CRC-ARQ 


Symmetry 


Reserved 


1 


Bandwidth 


2 


DVP 


Transport Protocol 


3 


Reserved 


4 



10 



DCS1900 ignores this information element in the N Notes 
RMT Service Request message . 

Table 4-62.1 Bandwidth 
value meaning 



15 



20 



25 



0-255 



<TBD> 



value 



Table 4-62.2 CRC-ARQ 
meaning 



00 


Neither CRC nor ARQ in effect 


01 


Reserved 


10 


CRC in effect 


11 


CRC and ARQ in effect 


Table 4-52.3 DVS 
value meaning 


00 


Reserved 


01 


Voice service requested 


10 


Data service requested 


11 


Signaling service requested 



30 
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Table 4-62,4 Synunetry 



value 



GO 


Symmetric Bandwidth 


01 


Maximum MS bandwidth minimum BS bandwidth 


10 


Maximum BS bandwidth minimum MS bandwidth 


11 


Variable symmetry 



Table 4-62.5 Transport Protocol 



value 



0 


8 bit transparency mode. 


1-255 


Reserved for future use 



Table 4-63 Service Provider [O, M] 
This 16 bit information element, when present in a base-to- 
user signaling message, identifies the PCS service provider that 
operates the base station 105. When present in a user- to-base 
signaling message, it specifies the identification of the PCS 
service provider that the user station 102 wishes to use. The low 
order bit of this 16 bit element resides in Bit 1 of Octet 1 while 
the high order bit of this 16 bit element resides in Bit 8 of Octet 
2 . 



25 



30 



8 



Bits 
6 5 



Octets 



2 



16 bits of unique Service Provider 
Identification number 



Table 4-64 Service Type 
The Service Type information element indicates the type of 
service being requested. 
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value meaning 



5 



0000 


Null Service. Indicates that service 
resources are not yet being requested. 


0001 


Normal call 


0010 


Emergency (911) call 


0100 


Short Message Service 


1000 


Supplementary Service Activation 



When this information appears in a N Notes RMT Handover 
Request message, the only legal values are Normal Call and 
Emergency Call. Furthermore, DCS1900 may not be able to provide 
this element, in which case it will default to Normal Call. 



15 Set/Query [M] 

The field will have a value of 0 to indicate that query 
operation is to take place and a value of 1 to indicate that a set 
operation is to take place. 



20 



25 



30 



Table 4-65 Slot Quality [O] 
The Slot Quality information element identifies the radio 
frequency quality of the channel (time slot) in which the 
information element was received. To allow for flexibility, the 
meaning of the values is implementation specific. 



Bits 
5 4 



Octets 



8 bits Slot Quality 



value 


Slot Quality 


0 


<TBD> 


255 
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Table 4-68 Surrounding Base Table (SBT) [O] 



Bits 



Octets 



10 



8 7 6 5 


4 3 2 1 


SBT Sequence # 


SBT Length 


Base 1 Info 


Base 1 Code Index 


Base 1 Frequency Index 


Base 2 Info 


Base 2 Code Index 


Base 2 Frequency Index 




Base <SBT Length> 
Info 


Base <SBT Length> 
Code Index 


Base <SBT Length> Frequency Index 



15 Note that the table is of variable length. When it occurs in 

the CT-RCP message, it can store a maximum of 10 base index pairs, 
when it occurs in the CT-BAI message, it can store a maximum of 11 
base index pairs. 

Includes the frequency index and the code index for the 

20 <ith> surrounding base station 104. 

Table 4-68.1 



25 



30 



SBT: Base <i> Info 
Information about Base <i> to help the user station 102 
rank the base station 104 . 



Bits 




8 


7 


6 


5 


Meaning if Bit is Set 


0 


0 


0 


1 


This base station represents a Micro 

Cell 


0 


0 


1 


0 


This base station is concentric with 
current base station 


0 


1 


0 


0 


Reserved 


1 


0 


0 


0 


Reserved 
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Defines the number of base stations 104 which are 
contained in this SBT segment. 

If the number of surrounding base stations 104 exceeds 
the maximum that can be held in the message (10 in the case of the 
5 CT-RCP) , this number will indicate the number of following messages 
(CT-ASIs) required to transmit the rest of the data. The number 
will thus serve as: 

An indication of the existence of more surrounding 
bases than will fit in the table. 
10 -A unique identifier of which subset of base stations 

104 are contained in this SBT. E.g., a value of 
zero means this is the only (or last) set of SBT 
entries. A value of 2 means that there will be two 
additional SBT segments following the current one. 

15 

Search Type [M] 

The Search Type information element specifies the type of 
search being requested. 



20 



8 



Bits 
5 4 



Octets 



8 bits of Search Type 



Value 


Description 


0 


Specific PLMN 


1 


Specific PLMN; if not 
found give PLMN List 


2 


PLMN List 


3 


Specific Zone 


4 


Specific Zone; if not 
found give Zone List 


5 


Zone List 


6 - 255 


Zone List 
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Search Time [M] 

The Search Time Information element specifies the amount of 
time in milliseconds associated with a search request. 



10 



15 



Bits 
5 4 



32 bits of Search Time 



Octets 

1 
2 
3 
4 



Search Time : Search Request 
The Search Time information element specifies the maximum 
amount of time to perform the requested search. 

Search Time: Search Confirmation 
The Search Time information element specifies the actual 
amount of time spent performing the requested search. 



20 



Service Provider [O, M] 



25 



Table 4-69 System Type [O] 
The System Type information element identifies the code set of 
the supporting infrastructure. 



Bits 
5 4 



System Type 



Octets 



30 



value 



System Type 



0 


DCS1900 


1 


Bellcore Generic C 


2-255 


Reserved 



35 



>JSDOCI0: tWO 9713353A1.I.> 



wo 97/13353 



PCT/US96/I5190 



10 



15 



20 



131 



Table 4-70 TCID [O, M, N, I] 

The TCID (Transport Channel ID) information element specifies 
the Transport Channel to which data in the message belongs. 



8 



Bits 
5 4 



Octets 



Reserved 



6 bits of TCID 



message , 



When Transport Data is embedded in an O Notes__RMT_CT-TRA 
the TCID is embedded in the Message Type. In this case: 
bit 8 of the Message Type is set to 1 . 
bit 7 is used for segmentation: it is set to l for 
the last segment of a Transport Message and to 0 for 
all other segments. 



TCID 


Meaning 


0 


DCS1900 (SAPI 0) 


1 


Reserved 


2 


Reserved 


3 


DCS1900 (SAPI 3) 


4-63 


Reserved 



Defaults: When the Protocol in use is DCS1900, the TCID 
must be zero in all cases except when SMS traffic is being sent. 

2 5 Table 4-71 Transport Data [O, M, N, I] 

The Transport Data information element contains 19 bytes (152 
bits) of application level data transferred between the user 
station 102 and the base station controller 105. The low order bit 
of the data resides in bit 1 of octet 1 and the high order bit 
30 resides in bit 8 of octet 19. The Transport Data information 
element may be larger (e.g., up to 260 bytes using LiAPD) for 
interfaces other than the O- interface, which is restricted in size 
due to the length of the over-the-air information packet. 



35 
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15 



20 



25 



30 



132 



Bits 
6 5 



Octets 
2 1 



152 bits of Transport Data 



1 
2 



19 



TC Data [M, W, I] 

The TC Data Information element contains upper layer Transport 
Channel data. If there are more than 19 octets of TC Data, the TC 
Data information element will be segmented into 19 octet Transport 
Data [O] segments for transfer over the O interface. 



Bits 
4 



:DC Data Length> octets of CTC Data 



Octets 

1 
2 
3 
4 

variable 



Data Length [M, N, I] 

The TC Data Length information element specifies the number of 
octets of TC Data to follow. 



Octets 



8 



Bits 

6 5 3 

16 bits of TC Data Length 
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Table 4-66 TCID [O, N, I] 

The TCID (Transport Channel ID) information element specifies the 
Transport Channel to which data in the message belongs. 



10 



15 



20 



25 



30 



Bits 


Octets 


8 


7 6 5 4 


3 2 1 




Network Type 


Application 
Instance 


1 



When Transport Data is embedded in an 0-Notes_RMT_CT-TRA 
message, the TCID is embedded in the Message Type. In this case: 

• bit 8 of the Message Type is set to 1 {in all other cases 
it is set to O) . 

• bits 1 -7 identify the Transport Channel for the message 
data . 

TCID: Network Type 

The Network Type Field consists of 3 bits which are used to 
identify a particular external network to which the CCT system is 
connected . 



Value 


Meaning 


0 


DCS1900 


1 


Reserved 






6 


Reserved 


7 


OAM 



TCID: Application Instance 
The Application Instance Field consists of 4 bits which are 
used to identify a particular Application Instance within the 
specified Network. 
For DCIS1900, the values are: 
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Value 


Meaning 


0 


CC/SS/MM 


1 


Reserved 


2 


Reserved 


3 


SMS 


4-15 


Reserved 



For OAM, the values are: 



Value 


Meaning 


1 0-15 





15 



20 



Table 4-67 Traffic Type [M] 
The Traffic Type information element specifies a type of B 
Channel traffic. (The values for Traffic Type are the same as 
those for the DVS field in the Resource Request Data Information 
Element . ) 



Bits 
5 4 



8 bits of Traffic Type 



Octets 



25 



30 



Value (hex) 


Description 


GO 


Reserved 


01 


Voice 


02 


Data 


03 


Signaling 



Transport Data [O] 

The Transport Data information element contains 17 bytes (152 
bit) of application level data transferred between the MS and BS . 
It will either contain the same data as the TC Data [M, I] 
information element or will contain a 19 byte segment of that data, 
Segmentation is performed in the MS-OTA and BS-OTA 



4SDCC1D: <WO 9713353A1_I_> 



wo 97/13353 



135 



PCT/US96/15190 



10 



15 



20 



25 



Bits 
5 4 



152 bits of Transport Data 



Octets 

1 

2 



10 



Transport Retry Count [M] 

The Transport Retry Count information element specifies the 
number of times to retry transmitting the data contained in the 
Transport_Req . 

Bits Octets 
8 7 6 5 4 3 2 1 

1 



8 bits of Transport Retry Count 



Transaction Hint [O] 

The MS provides the Message Type of the first CT message it 
plans to send after it has acquired the link. 

Transaction Hint Qualifier [O] 

The MS provides additional information (not implicit in the 
Message Type) concerning the transaction it plans to perform. 



Transaction Hint: RRQ (Registration Request) Qualifier 



The MS will provide the Registration Type to allow the BS to 
30 know what kind of registration the MS will be requesting. 

If the MS is requesting a Network Level Registration, the BS 
can use the MAP Information Elements in the CT-SPO message to put 
the MS directly into Slow Control Traffic. 

If the MS is requesting a BS Level Periodic Registration, the 
35 BS can use the CI and Cause Elements in the CT-SPO message to tell 
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the MS that it is registered (the Cause IE) and that the BS does 
not expect to hear from it again for this transaction (CI II set to 
zero) . 

5 Transaction Hint: SRWQ (Service Request) Qualifier 

The MS will provide the Resource Request Data Information 
Element to allow the BS to know whether this is a 911 call or a 
normal call and the minimum and maximum acceptable Channel Rates 
for the call . 

10 If the MS is requesting a 911 call and there is no channel 

available to put the call through, the BS can either: 

1. use the Map Information Elements in the CT-SPO to 

put the MS directly into Slow Control Traffic to 
wait for a channel to become available or 

15 2- Use the CI and Cause Elements in the specific poll 

to tell the MS that it is queued and will be paged 
as soon as there is a channel available (the Cause 
IE) and that the BS does not expect to hear from it 
again until it is paged (CI IE set to zero) . 

20 

Transaction Hint: THR (Terminating Handover Request) 
Qualifier 

The MS will provide the Resource Request Data Information 
Element to allow the BS to know whether this is a 911 call or a 
2 5 normal call and the minimum and maximum acceptable Channel Rates 
for the call . 

Transport Method [O, M, I] 
The Transport Method information element contains data to 
30 specify bandwidth, protocol and other control information for 

TRAUs . Its format differs based on the value of the DVS field in 
the Resource Request Data information element. If the DVS field 
indicates voice, then the format of Transport Method is: 



MSDOCID: <WO 9713353A1_I_> 



wo 97/13353 



137 



PCT/US96/I5190 



10 



15 



20 



Bits 
5 4 



Speech Algorithm 



Reserved 



Reserved 



Reserved 



Reserved 



Octets 

1 
2 
3 
4 



If the DVS field indicates data, then the format of Transport 
method is: 



Bits 
5 4 



Network Rate Adaptation 



Reserved 



Reserved 



Reserved 



Transport Method: Speech Algorithm 



Octets 

1 
2 
3 
4 



Value 


Meaning 


0 




1 




2 




3 





25 



30 
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Transport Method: Network Rate Adaptation 



10 



Value 


Meaning 


0 


GSM Transparent 9 , 6 
kbps 


1 


GSM Transparent 4 . 8 
kbps 


2 


GSM Transparent 2 . 4 
kbps 


3 


GSM Transparent 1 . 2 
kbps 


4 


GSM Transparent 60 0 
bps 


5 


GSM Transparent 
1200/75 bps 


6 


GSM Non- Transparent 
12 kbps 


7 


GSM Non -Transparent 6 
kbps 



Table 4-72 UPT [O, M, N, I] 

This 80 bit information element is the Universal Personal 
Telecommunications number that has been ranted to the subscriber 
operating the user station 102, and consists of 20 four-bit 
characters . 



20 



25 
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Bits 
5 4 



80 bits of Universal Personal 
Telecommunications Number 



PCT/US96/15190 



Octets 



2 1 



10 



Table 4-73 Value [M] 

The Value field contents are variable depending upon the item 
in the OTA which is being queried or modified. 

Table 4-74 Zone [O, M, N, I] 



20 



The Zone and the Base ID combine to uniquely identify each 
base station 104 in the world. The precise format of the Zone 
depends upon the value of the System Type . 



25 



30 




A subset of the Zone, uniquely identifies the operator of 
the network. This portion is called the PLMN (Public Land Mobile 
Network) and, in the case of DCS1900 Systems, consists of the MCC 
and MNC. 
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Table 4-74.1 Zone: DCS1900 Systems 

For DCS1900 Systems, the Zone is the Location Area Identifier 
(LiAI) ; it consists of a 16 bit Mobility Country Code (MCC) , an 8 
bit Mobility Network Code (MNC) and a 16 bit Location Area Code 
(LAC) . 

Bits Octets 
87654321 



16 bits of unique MCC 



8 bits of unique MNC 



16 bits of unique LAC 



1 
2 
3 
4 
5 



Table 4-74.1.1 LAC 

The LAC is an Location Area Code. The combination of the Base 
ID, MCC, MNC and LAC uniquely identify a given base station 104. 



20 



Bits Octets 
87654321 



16 bits of Location Area Code 



1 
2 



25 



Table 4-74.1.2 MCC 



30 



The MCC is a Mobility Country Code. The combination of 
the Base ID, MCC, MNC and LAC uniquely identify a given base 
station 104. 



Bits 
6 5 



Octets 
2 1 



16 bits of Mobility Country Code 



1 
2 



JSDOCID: <WO 9713353A1_L> 



wo 97/13353 



141 

Table 4-74.1.3 MNC 



PCT/US96/15190 



The MNC is a Mobility Network Code. The combination of the 
Base ID, MCC, MNC and LAC uniquely identify a given base station 
104 . 

Bits Octets 
87654321 



8 bits of Mobility Network Code 

3^0 The operation of Notes to communicate Information 

Elements comprising user and signaling data within the 
communication system 101 can be explained by way of example with 
respect to the "Base ID" Information Element shown in Table 4-13. 
The Base ID is a 32-bit Information Element uniquely identifying 
15 within a particular message or Note a specific base station 104. 
The Base ID Information Element may be communicated within the 
communication system in O-Notes, M-Notes, N-Notes and I -Notes. For 
example, the Base ID Information Element is contained within the 
"Circuit Switch Complete" N-Note shown in Table 3-9, the "Circuit 
2 0 Switch Complete" M-Note shown in Table 1-7, and the "CT- CSC 
(Circuit Switch Complete)" O-Note shown in Table 2-10. 

The operation of Notes to execute internal operations 
within the communication system 101 may be explained with respect 
to a process for switching communication paths for a mobile user 
25 station 102 within the communication system '101 . Such a switch 

might occur, for example, when a user station 102 begins to leave a 
cell 106 for a first base station 104 with which it is 
communicating, and begins to enter a second cell 106 for a second 
base station 104. In that case, it may be desired to handoff 
30 communication with the user station 102 from the first base station 
104 to the second base station 104 . 

Figure 13 is a flowchart setting forth a procedure for 
communicating the completion of a handoff of a mobile user station 
102 between a first base station 104 and a second base station 104 
35 in the communication system 101, wherein the two base stations 104 
are connected to the same base station controller 105. 
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In a first step 1310, the base station controller los 
initiates a process to switch the call connection from the first 
base station 104 to the second base station 104. In a next step 
1320, the base station controller 105 communicates a Circuit Switch 
Complete N-Note across the N- Interface 620 between the base station 
controller 105 and the first base station 104. The format for the 
Circuit Switch Complete N-Note is given in Table 3-9 and includes 
an Information Element containing the Base ID of the second base 
station 104 , 

In a next step 1330, the base station 104 communicates a 
CT-CSC (Circuit Switch Complete) 0-Note across an O-Interface 610 
between the first base station 104 and the user station 102. The 
format for the CT-CSC (Circuit Switch Complete) O-Note is given in 
Table 2-10. As shown in Table 2-10, the CT-CSC (Circuit Switch 
Complete) O-Note passes along the Information Element for the Base 
ID of the second base station 104. 

The CT-CSC (Circuit Switch Complete) O-Note passes some 
common Information Elements from the Circuit Switch Complete N- 
Note, such as the New Base ID and HRef (Handover Reference Number), 
20 to the mobile user station 102. By contrast, the base station 104 
does not pass the PID (personal ID) Information Element to the 
mobile user station 102 in the O-Note, as the mobile user station 
102 already knows its own PID. The PID which is contained in the 
N-Note is used by the base station 104 so that it can identify the 
particular user station 102 for which the base station controller 
105 has completed a circuit switch. With the PID, the base station 
104 can determine the proper slot within its polling loop for 
transmitting the O-Note containing a CT-CSC (Circuit Switch 
Complete) message . 

Similarly, for each N-Note received from the base 
station controller 104 across the N- Interface, the base station 104 
uses some Information Elements for its own internal operations, and 
passes other Information Elements along to the mobile user station 
102. 

35 In a next step 1340, the mobile user station 102 

communicates a Circuit Switch Complete M-Note across an M- Interface 
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605 between the mobile communication transceiver in the user 
station 102 and an application end user hosted in the user station 
102. The Circuit Switch Complete M-Note contains the Base ID 
Information Element. The Circuit Switch Complete M-Note also 
5 contains other Information Elements (e.g., BSC ID, Facility) added 
by the mobile communication transceiver 603 in the mobile user 
station 102. By contrast, the Circuit Switch Complete M-Note does 
not contain the HRef Information Element which is used by the 
mobile communication transceiver 603 to identify the particular 
10 handover request. 

Layer Two O- Interface Definition 

This section presents data link layer 424, Fig. 4A, the RF 
link protocol architecture of the O- Interface 610, Fig. 6. TDMA 

15 frame structures are defined and the underlying slot structure for 
TDD connection is presented. For example, a transmission, either 
from the base station or from the mobile user station, includes 
frame types and headers that are required to identify the specific 
purpose of that transmission. Additional information is provided 

20 to the receiving device that allows it to determine information 

bandwidth symmetry, whether error correction is applied and if the 
received transmission is part of an aggregated bandwidth 
connection. These processes are described in the following text. 

2 5 Frame Format 

Frame Format Normal 
Each normal frame is composed of sixteen TDMA time slots where 
duplexing is accomplished by providing TDD within each TDMA frame. 
A channel composed of one time slot per frame provides one 9.6 kbps 
30 full duplex radio path for raw data. The time slots are not 

numbered. The numbers are shown in Table 5.1 for reference only. 
There is no frame mark transmitted over the air. Proper slot 
synchronization shall be performed by timing. 

35 



3NSDOCID; <WO 9713353AlJ_> 



wo 97/13353 



10 



PCT/US96/15190 



144 



Frame Format Extended Range 
An extended range frame shall be composed of 8 TD^4A time slots 
where duplexing is accomplished by providing TDD within each TDMA 
slot. The slots are not numbered. The use of this is deployment 
specific and is used in applications where range is extended (the 
excess time in each expanded time slot is used for Guard Time to 
allow larger propagation delays for extended range) . The numbers 
are shown in table 5.1 for reference only. There is no index 
associated with the frame. Proper slot synchronization is 
performed solely by timing. Both frame format normal and frame 
format extended range have the identical frame time (20 ms) . 
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Table 5.1 

Nomal and Extended Range Frame Formats 
Channel Acquisition 

5 A mobile user station attempting to communicate with a base 

station shall seize at least one channel on that base station. 
This is accomplished by responding to a Base General Poll with a 
mobile user station General Response. The General Response for 
this mobile user station, the base station shall respond with a 

10 Specific Poll which contains the PID of this mobile user station. 

On reception of such a Specific Poll, the mobile user station may 
transition into the Traffic mode. 

Until the mobile user station receives a Specific Poll 
containing its PID, the mobile user station shall not seize the 

15 channel and must wait a pseudo random time based upon the PID and 
then try again in a manner similar to the backoff procedure of 
ANSI/IEEE 802.3. When the base station is ready to assign a 
channel to the mobile user station and initiate communications with 
the mobile user station, the base station shall issue a Specific 

20 Poll packet containing the PID of the mobile user station. 

Multiple Associated Signaling Time Slots per Frame 
Normal time slot synchronization shall be accomplished by 
timing. Both the base station and mobile user station shall know 

25 which time slots have been assigned for communication. The mobile 
user station shall send its signaling information to the mobile 
user station in the first half of the TDD time slot; the base 
station shall send its signaling information in the second half of 
the TDD time slot. The mobile user station shall synchronize and 

30 shall maintain timing synchronization on the base station 

transmissions. The mobile user station shall maintain timing 
synchronization with the base station for up to one second in the 
absence of received base station transmissions. 

If available, multiple time slots per frame shall be used for 

35 polling and signaling traffic. To accommodate this, the base 

station shall assign a temporary address known as the Correlative 
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ID CI, to the mobile user station on the first Specific Poll. This 
Correlative ID shall then be carried in further signaling traffic 
from the base station to the mobile user station. The mobile user 
station shall search for this ID in all traffic. The mobile user 
station can then respond to any signaling traffic time slot 
containing this Correlative ID. Unused Correlative IDs shall be 
maintained in a pool by the base station. When communication has 
ended between the base station and mobile user station, the 
Correlative ID shall be returned for reuse. 

Any available time slot may be used by the base station to 
continue signaling communications with the mobile user station. 
The last time slot used by the base station for signaling traffic 
will become the first time slot for bearer traffic use unless 
otherwise specified by slot mapping information given to the mobile 
15 user station by the base station. If the base station returns to 
signaling traffic at a later time on the current channel, the 
Correlative ID will still be effective, and the base station may 
use any available time slot for further control traffic. 

2 0 Asymmetric Channels 

Traffic flow between the base station and mobile user station 
may be either symmetric or asymmetric. The total number of bits 
per TDD time slot shall remain constant in either case. The flow 
shall be controlled by the base station acting upon the Bandwidth 
25 Request bit in the mobile user station to base station traffic 

header. The normal flow is symmetric with an equal number of bits 
(except for the header bits) assigned in each direction. The 
Bandwidth Grant bits in the header of the base station to mobile 
user station traffic channel shall establish the actual number of 
30 bits to be used in the next time slot of the channel. 

The base station shall assign TDD time slot bandwidth (number 
of bits) using the following algorithm: 

1. If only the base station (BS) requires additional 

bandwidth, then the base station shall be granted the 
additional bandwidth for the next time slot assigned to 
that mobile user station. 
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2. If only the mobile user station (MS) requires additional 
bandwidth, then the mobile user station shall be granted 
the additional bandwidth for the next time slot assigned 
to that mobile user station. 
5 3 . In all other cases, symmetric bandwidth shall be granted 

for the next available time slot assigned to that mobile 
user station . 

Broadcast Channe 1 s 

10 The asymmetry of the channel may be taken to its logical 

extreme by granting the entire bandwidth of each time slot to the 
base station to produce a broadcast channel. The nature of this 
channel shall be indicated by the Bandwidth Grant bits in the base 
station time slot header (they apply to the next time slot in the 

15 channel) . Multiple simultaneous Broadcast Channels shall be 

supported. During broadcast, the bits normally used for the D- 
Channel shall be used as a broadcast identifier. Since this occurs 
in the same position as the Correlative Identifier, the difference 
in usage is signaled by the Bandwidth Grant bits. 

20 

Super Channel 

The ability to assign multiple time slots in the frame may be 
negotiated for and assigned to an individual mobile user station. 
The negotiation may take place at any time via signaling traffic. 

25 The assigned TDD time slot, if available, shall be communicated by 
the base station to the mobile user station via the OTA Map Type 
and OTA Map information elements. Channel synchronization shall be 
maintained by the mobile user station based on frame timing. 

The handover procedure shall account for the multiplicity of 

30 time slots per channel assigned to the transferring mobile user 

station. A base station shall have the appropriate number of time 
slots available to become a candidate as a terminating base station 
for handover. The time slots need not be available in the same 
positions in the frame as. those in the originating base station. 
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Logical Sub Channel 

A mobile user station need not be granted a time slot in 
every frame. Time slots may be granted in frames separated by 
an integral number of intervening frames. The maximum limit on 
5 the separation of frames allocated to a single mobile user 

station is one time slot every 25 frames or every 0.5 seconds. 
This would yield a channel with a raw full duplex rate of 384 
bps . 

10 Multiple Mode Traffic 

A single mobile user station may have multiple connections 
established through the Base Station to the network via multiple 
channels. One channel may, for example, be assigned to audio 
traffic while other channels are devoted to data traffic. 
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O Wotes_RMT Protocol : Packet Formats 
There are two basic types of OTA Packets: 

1. Signaling Packets, which are used to transfer control 
information between the base station and the mobile 
user station, and 

2. Bearer Packets, which are used to transfer Voice and 
Data Traffic between the base station and the mobile 
user station. 

Two packets are transmitted during each TDD time slot, one 
from the mobile user station to the base station and one from 
the base station to the mobile user station. Each packet is 
formatted to be entirely self-contained within its portion of 
the slot. Error correction and detection is achieved by use of 
the Frame Check Word (FCW) which appears in all packets. Error 
30 recovery of individual packets is left to the higher Protocol 
handlers of network layer 422, although the ARQ mechanism may 
be optionally employed. 

The only difference between the Packets sent by the Base 
Station and those sent by the Mobile Station is the size (and 
35 format) of the Header: 23 bits in Packets originating from the 
base station and 17 bits in Packets originating from the mobile 
user station. 
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Data is not transmitted over-the-air in octets (multiples 
of 8 bits) . The lengths of the information elements shown in 
the following formats and packets are the lengths seen by the 
controlling software . 
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Signaling Packet Format 

Signaling Packets are always symmetric, thus there are no 
High or Low Bandwidth Packet Formats. (It is possible that 
asymmetric signaling packets will be defined in the future.) 



Information Element 


Length in Bits 


Header (17 or 
23 bits) 


24 


D Channel 


8 


B Channel 


160 


Reserved for FEC 


32 


FCW 


16 



<Total Bits in mobile user station> 



240 



Bearer Packet Format 

Bearer Packets are used to transmit Voice or Data traffic 
end-to-end through the CCT system. There are three varieties of 
Bearer Packets: high bandwidth, low bandwidth and symmetric 
bandwidth. (From the base station, there is also a broadcast 
variety of Bearer Packet.) 

When the OTA link is symmetric, both the base station and the 
mobile user station will transmit a symmetric bandwidth packet. 
When the OTA link is asymmetric, one side will transmit a high 
bandwidth packet and the other side will transmit a low 
bandwidth packet. Which side transmits which size packet will 
be determined by the Symmetry Bits in the base station Header 
transmitted during the previous time slot in which the base 
station and mobile user station exchanged packets. 



35 
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High Bcmdwidtih Packets 

High Bandwidth Packets are used to transport large amounts 
of bearer traffic or signaling traffic between the base station 
and the mobile user station. 
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Information Element 


Length in Bits 


Header (17 or 
23 bits) 


24 


D Channel 


8 


B Channel 




FCW 


16 



Layer 3 Air Interface Description 

0_Notes_RMT Protocol: Control Traffic Packets 
This section supplies the message formats that are 
intrinsic to network layer 422, Fig. 4A, Layer 3 Air Interface 
protocol architecture of O-Interface 610. Fig. 6. These formats 
are described in detail to include the definition of the 
message, the required number of bits or field size and 
application of the message. This section describes the 
functions that are one level above the frame and slot structure 
but include the critical components that provide differentiation 
between types of traffic. Call flow diagrams are dependent on 
the message set described in this section. 

Level 2. network layer 422 signaling information shall be 
contained in data packets. The details of these packets are 
given in the following section. Each signaling message shall be 
contained in one data packet . 

Note that the data portion of all Control Traffic Packets 
is limited in length to 160 bits (20 octets) . The remaining 32 
bits (4 octets) are specifically reserved for future use by a 
FEC (Forward Error Correction) mechanism if such a mechanism 
proves necessary. 

Special Interpretation of D Channel Information 
Since the CT-GPO is to all listening Mobile Stations, the D 
Channel does not contain a Cl as it does for other signaling 
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messages. Rather, it will be used for the Paging/Broadcast 
Countdown Information Element. 

Special Interpretation of D Channel Information 
As with all CT messages, the D Channel in the CT-GRP 
messages is used for the CI (Correlative ID) . For an MS 
acquiring a link for the first time (i.e., no currently active 
link), the value of this field will be zero. This includes both 
MSs without any active link plus those MSs (in the future) which 
are acquiring an additional active link. For an MS which 
currently has an active session, and which is acquiring a link 
as part of lost link recovery or to perform signaling without 
interrupting its bearer traffic, this field will contain the 
current Cl . 



Special Interpretation of D Channel Information 
The D Channel in the CT-SPO message is used for the Cl 
(Correlative ID). Normally, this is how the MS learns the Cl's 
value for the first time. There are cases where the BS has 
20 learned all it needs to know from the Transaction Hint given by 
the MS in its CT-GPR message. In these cases, the BS will 
respond to the MS with a CT-SPO message whose Cause information 
element (IE) provides the requisite information to the MS to 
complete the transaction. The Cl of this IE will be zero, which 
25 the MS interprets as meaning that the BS does not expect to hear 
from it again. 

The BS will use the Correlative ID IE in the CT-SPO message 
to either assign a new Cl to the MS, or to tell it (with a value 
of zero) that it does not want the MS to respond again (except 
30 for a CT-ACK) . The most likely reasons for a Cl of zero is that 
the BS has all the information it needs for a BS Periodic 
Registration or for 911 queuing, but there may be other reasons 
(which will be identified in the Cause information element) . 

35 0_Notes_RMT Protocol: Using The D- Channel 

The D-Channel is a one-byte element of the OTA Packets 
which is used as a Secondary Signaling Channel for slow (or very 
short) signaling. 
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D- Channel Data Rate 
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D- Channel Usage 

When the main circuit is used for Signaling, the D-Channel 

30 is used for : 

# Correlative ID: In all Signaling Traffic (CT- 
messages) except for General Polling Messages. 
General Polling Messages i.e., CT-GPO and future 



MSCXX;rD: <WO 9713353A1_L> 



wo 97/13353 



PCT/US96/15190 



10 



15 



153 



messages --do not contain a PID (or a CI) because 
they are addressed to multiple MSs . 
• Reserved: The D-Channel in General Polling Messages 
is reserved for future use. Possible use includes a 
count down event timer to alert all mobiles to the 
beginning of an event such as a Paging loop or a 
broadcast message sequence, and b) a grouping message 
which identifies a group of MSs for which the General 
Polling Message is targeted. 

When the main circuit is used for Bearer Traffic, the D- 

Channel is used for: 

• Transport Notes whose channel preference includes the 
D-Channel. These notes generally contain information 
which is not critical, e.g., SMS messages. 

# Very short OTA signaling transactions such as a MS's 
request for a TSI or a brief ASR/ASI type transaction 
e.g., containing the MS's distance from the BS . 
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D-Channel Protocol 

When the main circuit is being used for Bearer Traffic, all 
byte values in the D-Channel are legal as data. There are a few 
byte values which also have meaning as signaling information. 
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Value 
(hex) 


Meaning 


FF 


Filler 


FE 


Escape 


FD 


SOM (Start -of -Message) 


FC 


EOM (End-of -Message) 


FB 


Instant Request: TSI 


FA 


Instant Request : 
Separate Signaling 
Channel 



35 



Filler 

The Filler byte is send in the D-Channel whenever there is 
nothing else to send. The ARQ MSG# is never bumped for it and 
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it is never re- sent in response to the ARQ NAK unless there is 
nothing else to send. 

Escape 

5 The Escape byte is sent in the D- Channel as an immediate 

prefix to any signaling byte -- including the Escape byte 
which appears in the data being sent. 

SOM (Start -of -Message) 

-LQ The SOM Byte is sent to signal the beginning of a new 

Transport Note. It is required because of the ability to switch 
between the D and B channels for the transmission of the 
Transport Note. The character immediately after the SOM will be 
any legal 0_Note Message Type; if the Message Type is one of the 

15 special signaling bytes, it will be prefixed with the Escape 
byte . 

EOM { End -of- Me ssage ) 
There EOM byte signals the end of a message. It will be 
followed by one of the following: 
20 O a Filler byte, 

O an SOM signaling the beginning of a new message, 
O one of the Instant Request signaling bytes. 



Instant Request : TSI 
25 The IR (Instant Request) : TSI byte is a "single -byte 

message" which is used to request a Time Slot Interchange. 
Since it is a single byte in length, it does not require either 
an SOM or an EOM. 

The IR:TSI command is used by the MS to ask the BS to 
30 perform a TSI; the BS's reception of the IR:TSI command is 

confirmed by the ARQ bits of the BS's response message. The 
BS's acceptance of the TSI request is evidenced by the 
appearance of either a non-zero Next Slot Pointer in the header 
and an IR:TSI byte in the D-Channel (if the circuit is a single 
35 channel) or by the appearance of a CT-STL message and the MS's 
CI in the D-Channel (if the circuit is either sub-rate or super 
rate) . 
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The BS can initiate a TSI by the same mechanism --a non- 
zero Next Slot Pointer in the header and an IR:TSI byte in the 
D-Channel of the same packet. 

5 Instant Request: Separate Signaling Channel 

This is a "single-byte message" which is used to request a 
Separate Signaling Channel. Since it is a single byte in 
length, it does not require either an SOM or an EOM. 

The IR: Separate Signaling Channel command is used by the MS 
10 to ask to BS to establish a separate signaling channel so that 
the MS may perform some higher speed signaling without 
preempting the existing B-Channel. The BS will grant the 
request if it can, in which case it will send a non-zero Next 
Slot Pointer in the header and an IR: Separate Signaling Channel 
15 byte in the D-Channel of the next packet. 

The BS can also initiate the Separate Signaling Channel by 
the same mechanism -- a non-zero Next Slot Pointer in the header 
and an IR: Separate Signaling Channel byte in the D-Channel of 
the next packet . 

20 

Data 

The 0_Note Message Type byte will be followed by one or 
more bytes of data, comprising the information elements of an 
O_note. Whenever one of the signaling bytes appears as a data 
25 bye, the segmenter will prefix the byte with. an Escape byte. 

All zero bytes at the end of the note -- the Reserved 
bytes^--will be omitted. It will be the responsibility of the D- 
Channel Segmenter to remove the bytes on transmission and to 
reinstate them on reception, if appropriate. Note that zero 
30 suppression will not occur for CT-TRA messages since there are 
no Reserved bytes. 

Encryption 

If encryption is enabled on the D-Channel, it will occur on 
35 the date (except the Message Type) before the note is presented 
on the D-Channel Segmenter. Byte stuffing (i.e., the process of 
prefixing Escape bytes to ambiguous data bytes) is performed on 
the encrypted data . 
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Delayed or No Response To An IR (Instant Request) 

The MS must be prepared for the possibility that an IR will 
not be immediately responded to for two reasons: 

1. The BS does not respond to the request because it does 
not have the resources to satisfy the request . 

2. The BS doesn't have time to process the request before 
it must respond. It may still honor the request 
during the next slot. If it does so, it will have the 
same effect as if the BS had initiated the request; it 
will be effective when the MS honors the Next Slot 
Pointer by responding in that slot. If the MS does 
not respond, the BS must assume that the MS did not 
hear it and proceed accordingly. 



15 



It is, of course, possible that the last non-Reserved 
byte(s) in the 0_Note will be zero. This will not matter, since 
they will be recovered during re-segmentat ion . 

If the BS doesn't have time to respond immediately but 

2 0 prepares to do so next slot, and the MS decides to 

preempt the bearer during the next slot, the BS will 
interpret the second request as a duplicate request 
and will ignore it. It will appear to the MS that the 
BS had responded to its second request immediately. 
25 3, The MS D-Channel Segmenter did not ^send the request 

because the D- Channel is in the process of sending an 
Escape secfuence . Specifically, an Escape was sent in 
the D-Channel last slot and the IR request cannot be 
sent this time or else it would be treated as a data 

3 0 character and the true data character would be treated 

as a command or as data when it appeared, unescaped, 
in the next slot. If an Escape sequence is in 
progress, the D-Channel Segmenter will notify the MS 
OTA it will not save the command to send next slot 
35 and the MS OTA will either re-send the request next 

slot or will adopt another strategy (e.g., sending a 
control message in the B- Channel) . 
4. If a D-Channel command is required as part of the BS's 
response and if the BS D-Channel Segmenter is in the 
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process of sending an SOM or escape sequence. If this 
is so, the D-Channel Segmenter will notify the BS OTA 
-- it will not save the coimuand to send next slot 
and the BS OTA will either re-send the response next 
slot or will adopt another strategy (e.g., sending a 
control message in the B-Channel) . 

Procedures & Algorithms 

This section describes procedures and algorithms which are 
integral to the OMNI_Notes protocols (common to 0,M,N,I,). 



ARQ 

The ARQ, Automatic Repeat Request, mechanism provides a 
first level of protection against over-the-air errors. It 
relies on three one-bit fields in -the header of each 0_Note 

packet : 

1. B- Channel Enable, 

2 . ACK and 

3 . MSG# . 

The D-Channel is always protected by ARQ. If the B-Channel 
Enable bit is set, then the B-Channel is also protected by ARQ. 
Other than determining the Channels protected, the bit has no 
impact on the ARQ mechanism. The term message designates -for 
this discussion of the ARQ mechanism -either the D-Channel or 
25 both the D- and B-Channels as determined by ^the B-Channel Enable 
bit . 

If the incoming packet -the entire packet, not just the 
message-is error free, the receiver will set the ACK bit in its 
outgoing packet. If the incoming packet contains errors, of if 

30 there is no packet received when one is expected, the receiver 
clears the ACK bit-sets the NAK value-in its outgoing packet. 

If the incoming packet is error free, the receiver compares 
the MSG# of the incoming message with the MSG# of the previously 
received message; if they are the same, the receiver ignores the 

3 5 new message (with the exception that if the new message is a CT- 
HLD, its SCT parameters will be checked for OTA mapping 
information) . 

If the incoming packet is error free and the ACK bit is 
set- indicating that the sender received the last message from 
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the receiver without error, the receiver will complement - i . e . , 
increment modulo 2 -the MSG# bit and send the new message (i.e., 
the next message it has to send) in its outgoing packet. 

If the incoming packet is error free and the ACK bit is 
cleared- indicating that the sender encountered some sort of 
error in the last message from the receiver-or if the incoming 
packet is not error free, or if no packet is received, the 
receiver will resend the same message and MSG# that it sent last 
time in its outgoing packet. 

In the context of ARQ processing, the CT-HLD 0_Note 
requires special handling. It is basically a filler and is 
transparent to ARQ; aside from being used to enter or change SCT 
it does not contain significant information and so it never 
needs to be retransmitted. The MSG# bit is not complemented 
when CT-HLD messages are sent. (A CT-HLD message will never be 
sent when there is another message outstanding; this includes 
the case where the message is outstanding because it was not 
successfully ACKed in the ARQ response from the receiver. Thus, 
the receiver can ignore the CTHLD- after checking if for SCT 
information.) When the receiver would normally resend the old 
message and the last message it sent was a CT-HLD, it will 
transmit a new message if one has arrived. It will complement 
the MSG# bit for the new message; the receiver will see the 
message as a new message to the last message received before the 
CT-HLDs were sent. 
In general : 

o the setting of the ACK bit in the outgoing packet is 

determined by the error status of the incoming packet; 

o the setting of the MSG# and the content of the message 
in the outgoing packet are determined by the state of 
the ACK bit in the incoming message; 

o whether the incoming message-assuming it was error 

free- is accepted or ignored is determined by the value 
of the MSGtt bit in the incoming packet (and how it 
compares with the MSG« bit of the previously received 
packet) . 
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Channels and Data Rates 

In a time division multiplexing system, a normal channel is 
composed of one slot per frame- i.e., the same slot each frame 
concatenated together over time. A channel supports a 9.6 KBPS 
5 circuit; the rate used for normal voice calls. The OMNI_Notes 
protocols support different circuit rates-both faster and 
slower-as well. 

For certain applications it is desirable to transmit 
signalling information at faster or slower speeds than those 
10 available with one channel per time slot for each mobile 

station. Faster rates are achieved by combining 2 or more slots 
--the same slots each frame-- into a circuit. This mechanism is 
called Aggregated Slot Traffic (AST) . 

Slower rates are achieved by skipping frames within a 
15 channel. These unused slots can be assigned to another MS, 

allowing the BS to interleave multiple MSs, each broadcasting at 
a slow rate, into the same channel. This mechanism is referred 
to as Slow Slot Traffic (SST) . 

Both AST and SST are controlled by the BS . Circuit rates 
20 for Bearer Traffic are negotiated between the MS and Network 

Applications and then requested of the OMNI pipe; circuit rates 
for Signaling Traffic are determined solely by the BS, although 
they may be requested by the MS. Once the rate has been 
determined, the BS assigns the appropriate OTA and backhaul 
25 resources and communicates these assignments ^to the appropriate 
entities within the OMNI pipe. 

Note that the circuit rates and slot assignments for the 
Bearer and Signaling portions of a call are independent. For 
example, even though a call may be assigned a specific set of 
30 slots for AST Bearer Traffic, Signaling Traffic for the call may 
be either carried as SST or it may be carried as AST using a 
different set of slots. 

Bearer Traffic 

3 5 Once the BS has assigned the resources for the Bearer 

portion of a call, it will communicate the Backhaul Map to the 
BSC via the Service Information message and the OTA Map to the 
MS via the CT-STL. message. 
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Since circuit rates other than 9.6 KBPS are normally used 
for data the descriptions of super- and sub-rate circuits are 
presented using data call terminology. This is not a protocol 
requirement, AST or SST circuits may be used for voice at the 
5 implementers option, although new vocoder algorithms will be 
needed on both the MS and the Network side. 



Aggregated Data 
SubRate Data 
10 Signaling Traffic 

Two types of Signaling Traffic are supported: Fast Control 
Traffic (FCT) and Slow Control Traffic (SCT) ; there is no normal 
i^ate as there is for Bearer Traffic. The "normal" Control 
Traffic rate is basically FCT with a Next Slot Pointer of zero 
15 (same slot, next frame). 

There are no special backhaul resources assigned for 
Signaling Traffic-Signaling Traffic is transported through the 
single signaling channel which was set up when the BS and BSC 
initially established communications, so there is no backhaul 

2 0 assignment to communicate to the BSC. 

The OTA resources assigned for Signaling Traffic are 
communicated to the MS via a mechanism dependent upon the type 
of signaling. FCT is dynamic. That is, there is no constant 
signaling rate, and the slot assignment for the next exchange is 
25 communicated to the MS via the Next Slot Pointer in the BS 
packet header . For SCT, the slot assignment is static 
(relatively) and is communicated to the MS via the CTSPO message 
when the circuit is established, or via a CT-HLD message if SCT 
is established or changed after the circuit is established. The 

3 0 Next Slot Pointer in each message does point to the next slot 

assigned for SCT, but the SCT rate may not be changed via this 
mechanism. 

Both types of Control Traffic depend upon two features of 
the OMNI_Protocol : The CI information element (which is 
35 essential for recovering from a missed packet) and the Next Slot 
Pointer (which tells the MS when the BS is expecting it to 
transmit) . 

ARQ functions normally for both FCT and SCT, 
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Fast Control Traffic 

Fast Control Traffic (FCT) is a method of accelerating 
signaling over the 0-Interface CI. It is of maximum value for 
time-critical operations such as handovers; it is of limited use 
5 when the signaling extends beyond the 0 Interface in either 
direction . 

FCT relies on several mechanisms: the Next Slot Pointer, 
the CI and the ARQ. FCT differs from Bearer AST in that it is 
very dynamic rather than being static (occurring in 
10 predetermined slots) . In each BS transmission, the packet 

header identifies the next slot in which the MS shall transmit. 
This is all there is to FCT when there are no errors. 

Error Recovery 
15 BS loses MS Message 

When the BS detects an error in an FCT message from the MS, 
it uses the standard ARQ procedure to recover. 



MS loses BS Message 
20 When the MS detects an error in an FCT message from the BS , 

it cannot use the ARQ procedure because it has an additional 
problem: it does not know which slot to transmit in because it 
didn't receive a Next Slot Pointer. Instead, it goes into a 
mode where it scans every packet transmitted by the BS, looking 
25 for a packet containing Packet Type = Signaling and the Cl which 
was assigned to the MS at the beginning of the session. When it 
finds the packet, it knows that the BS did not receive a message 
from it, since it did not transmit in the first part of the 
slot. Thus, the BS will, using the ARQ algorithm, have re-sent 
30 the message that the MS missed. This also gives the MS a new 
Next Slot Pointer, so it now knows where to respond. 

Since the MS also did not receive the ARQ bits in the lost 
packet, it does not know whether the BS received its last packet 
or not. (The ARQ bits in the current packet tell the MS that the 
35 BS did not receive the packet which the MS already knows it 

didn't send.) However, the MS has two pieces of information from 
which it can make some inferences: 

1. it knows whether ft sent an ACK or NAK in the last 
message , and 
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2. it knows whether the MSG# just received from the BS 
matches the last MSG# received. 

3 . The following table shows how the MS can determine 
whether to re- send old message or re -send new message 
based on these two pieces of information. 



ACK/NAK 

7 ^ cr f- 


MSG§ 


Did BS receive last message? 


NAK 


Different 


Not a possible outcome: if it 
occurs, resend last message and 
report protocol violation to 
OAM&P. 


NAK 


Match 


Don't know: re-send last message 


ACK 


Different 


Last message was received, send 
new message 


ACK 


Match 


Last message not received, re- 
send last message 



Having the new Next Slot Pointer and knowing whether to 
15 send a new message or resend the old message, the MS can now 
recover correctly from the lost message. 



Slow Control Traffic 

Slow Control Traffic (SCT) is a method of supporting a low- 
20 rate continuous signaling link. This provides the ability to 
multiplex several MSs involved in non- time-critical signaling 
sequences onto a single OTA channel to conserve bandwidth. This 
mechanism is used for registration and may be used for other 
activities if desired. 
25 SCT is a special case of Slow Slot Traffic (SST) . The BS 

can assign the MS to a subframe slot where the BS and MS both 
skip n (1^ n.s 31) frames between timeslots. This allows the BS 
to interleave several MSs which are in SCT Mode on the same 
timeslot , 

30 

BS Procedures 

Timeslot Management is the key to both FCT and SCT. If the 
BS does not wish to implement the more complex Timeslot 
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Management algorithm required for FCT or SCT, it can simply 
insure that Frame SubRate = 0, Frame Phase = 0 and Slot Phase = 
0. 

There are a couple of comments concerning SCT, below. 
5 •If the Service Type of the Link indicates that a voice 

or data circuit may be established, it might be 
advisable to not enter SCT mode. Otherwise a call 
might be lost because there were no longer resources 
available when it is time to leave SCT mode. This 
10 would work for a single slot call; it would not solve 

the problem for an aggregated data call. 

• If the BS recognizes a registration, CT-RRQ, it should 
attempt to enter SCT mode. 

• If a hold sequence proves lengthy, the BS might enter 
^CT at a fast rate-say every second frame-and then 
gradually slow the rate as the cumulative number of 
sequential CT-HLDs increases. 

MS Procedures 
2 0 To support SCT, the MS must: 

• Recognize and record* the Cl during Slot Acquisition 
and be capable of using it during error recovery, as 
it does for FCT. 

• Handle non-zero values of Frame SubRate, Frame Phase 
25 and Slot Phase and use them for Control Traffic, just 

as it does for Bearer Traffic. 

Entering SCT Mode 

SCT Mode can be activated only by the BS and only by 
30 sending an OTA Map specifying the desired rate in a CT-SPO or 
CT-HLD message. When the BS, by whatever heuristics it uses, 
decides it will be beneficial to put the MS into SCT, it will 
set the Frame SubRate and, optionally, the Frame Phase and Slot 
Phase fields in the OTA Map information element to non-zero 
35 values. The Next Slot Pointer in the header of the CT-SPO or 

CT-HLD message continues to point to an FCT slot. The MS and BS 
do not enter SCT Mode until the MS has signaled its acceptance 
of the SCT parameters by echoing them back to the BS in a CT-HLD 
message in the next FCT signaling slot. (If Frame Phase = 0 it 
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is legal for Slot Phase and Next Slot Pointer to point to the 
same slot, but until the BS receives the acknowledging CT-HLD 
message from the MS, it does not enter SCT mode.) The SCT 
parameters -Frame SuJbKate, Frame Phase and Slot Phase-are 
relative to the slot in which they are transmitted, even though 
SCT mode does not take effect until the MS has acknowledged. 

When the BS receives the acknowledging CT-HLD message, it 
will respond with a CT-HLD in its portion of the slot and enter 
SCT mode. The MS will interpret the ARQ bits of this message 
from the BS to determine whether the BS received the MS's 
acknowledging CT-HLD. If the ARQ bits indicate success, the MS 
will also enter SCT mode. If the ARQ bits do not indicate 
success, or if the MS does not receive the message without 
error, it will begin SCT Error Recovery. 

Maintaining SCT Mode 
Once SCT Mode has been entered, the MS and BS will maintain 
SCT mode by exchanging signaling messages at the rate specified 
by the Frame SuJbRate. Each CT-HLD message exchanged shall 
contain the same value of Frame SubRate and the Fran?e Phase and 
Slot Phase fields will equal zero. In particular, each CT-HLD 
message contains the sender's current understanding of the SCT 
rate. If the values are not the same, it means that the 
transmitting side is requesting a change of SCT mode. 

At some time while the MS and BS are in SCT, one or the 
other of them will have information (other than CT-HLDS) to 
transmit. These CT messages can be transmitted in SCT mode, in 
fact, the possibility exists that there will not be sufficient 
resources (time slots) available to exit SCT. 

Changing SCT Rate 
Once SCT mode has been established, the Frame Phase and Slot 
Phase fields in subsequent CT-HLD messages will typically be 
zero and the Frame SubRate will typically remain at the same 
value it had when SCT mode was established. It is possible that 
the BS may decide to either change the rate of the SCT while 
remaining within the same slot, or to shift the MS to another 
location in its slot map. It will do this by manipulating the 
values of the Frame SubRate, Frame Phase and Next Slot Pointer 
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fields. As with initial entry to SCT mode, the change will not 
take place until acknowledged via a CT-HLD reflecting the new 
rate-by the MS. This has the implication that the BS must 
maintain both slot maps until it is clear that the MS has 
5 accepted the change . 

Exiting SCT Mode 
In order for the BS and MS to exit SCT mode, there must be 
resources available- i . e . , there must be an available slot or 
10 slots that can be used for normal or FCT signaling. The balance 
of this section assumes that sufficient resources are available, 
see the discussion of SCT Error Recovery for system behavior 
when there are not sufficient resources to exit SCT mode. 

If the BS deteinnines that it is time to exit SCT mode, it 
15 will transmit a CT-HLD map with all of the SCT parameters -Frame 
Subi?ate, Fraine Phase and Slot Phase-set to zero. When the MS 
acknowledges-with a CT-HLD message with the SCT parameters also 
set to zero-the BS will transmit whatever signaling message it 
has to transmit in the same slot as the MS's acknowledgment; the 
20 Next Slot Pointer in this message will indicate a slot within 
the next frame and the signaling will revert to FCr signaling. 

MS Influences 

Although the BS controls SCT Mode, the MS is capable of 
25 requesting SCT entry, exit or rate change: 

If the MS and BS are in FCT mode, the MS can request entry 
of SCT mode by transmitting a CT-HLD message with a non-zero 
value of Frajne SubRate. The MS will, if possible, honor the 
MS's request by invoking SCT at a rate as close as possible to 
3 0 that requested by the MS. 

If the MS and BS are in SCT mode, the MS can request a rate 
change by transmitting a CT-HLD message with the desired Frame 
SubRate (different from the current frame subrate) ; it may not 
request a change in Frame Phase or Slot Phase, The BS will, if 
35 possible, honor the MS's request by initiating a change to a new 
subrate as close as possible to that requested by the MS. 

If the MS and BS are in SCT mode, the MS can request exit 
from SCT mode by transmitting a CT-HLD message with the zero 
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value for Frame SubRate. The MS will, if possible, honor the 
MS's request by exiting SCT. 

In all cases, the MS will know whether the BS has accepted 
or rejected the request by the values of the SCT parameters 
received in the next error free CT-HLD message. The requested 
rate will not become effective until the MS has acknowledged the 
change by echoing the SCT parameters to the BS in its next CT- 
HLD message. 



10 Error Recovery 

Because of the potentially long intervals between message 
exchanges while in SCT, special error recovery procedures are 
required when an error occurs in SCT mode. 

15 BS loses MS Message 

If the BS loses an MS message while attempting to establish 
SCT mode, it will continue with the attempt to establish SCT 
mode. Repeated lost messages will eventually prompt normal Lost 
Link Recovery. 

20 If the BS loses an MS message during SCT mode, it will 

'increment its leaky bucket" and attempt another transmission 
during the next assigned SCT slot. If the leaky bucket 
overflows, it will implement normal Lost Link Recovery and begin 
transmitting Specific Polls for the MS in the assigned SCT slots 

25 until its Lost Link Recovery timer expires. The OTA Map in the 
CT-SPO message will determine the signaling rate to be used when 
the link is recovered. 

MS loses BS Message 

30 If the MS loses a message while attempting to establish SCT 

mode, it will attempt to recover using the same technique 
defined for FCT; it will begin scanning for CT messages 
containing its Cl . If it sees such a message, it can respond in 
the slot indicated by the Next Slot Pointer in the CT message. 

3 5 If it does not see such a message after a reasonable amount of 

time-the amount shall be provisionable with a default setting of 
24 slots (1.5 frames) -it will attempt to re-establish the link 
by responding to a GPO with a CT-HLD message. The BS will 
recognize the Cl associated with the CT-HLD as belonging to an 
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MS that it thinks it is communicating with in SCT mode and will 
respond accordingly (probably a CT-HLD with the appropriate SCT 
parameters) . 

If the MS loses a message during SCT mode, it will 
5 increment its 'leaky bucket' and attempt another transmission 
during the next assigned SCT slot -this is why the BS must 
preserve the SCT map for this MS until it has 1) re-established 
the link, 2) gotten solid confirmation that the MS is switching 
to a different SCT map, or 3) given up after Lost Link Recovery. 
10 If the leaky bucket overflows, it will implement normal Lost 

Link Recovery, either initiating a handover, if appropriate, or 
searching for Specific Polls until its Lost Link Recovery timer 
expires . 

15 No Slot Capacity to Exit SCT 

If there are no available slots, then clearly the BS and MS 

cannot exit SCT mode. They will stay in SCT mode and continue 

signaling (non CT-HLD messages) until there are slots available. 

There is the risk that continuing to signal in SCT mode may 
20 cause timing problems for the higher level processes; if this 

occurs, the problems will be resolved by the higher level 

processes . 

Operation.'; and Management Of T he Base Station 
25 To simplify BS management a degree of abstraction is used 

when addressing entities within a BS . This is achieved by 
addressing NM messages using the Managed Object Class and 
Managed Object Instance. There must be in the BSC an object 
model with a complete data link layer 424 description for each 
30 object instance in the BS . When a message has to be sent to an 
object instance this mapping is used to find the correct link. 

The first connection is established from the BS site using 
a (semi-) permanently programmed default TEL All OAM&P 
procedures are sent on this connection. A further connection is 
35 established on the same TEI for Notes signaling. 

Object instances also have a network layer address. The 
instance number is used to address the object instance. Network 
layer address is used by the manager and agent to determine 
which object instance is being addressed. In this case the 
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agent must have this instance number (semi-) permanently 
programmed. 

For inter-operability , link configuration, default TEI 
assignment and instance numbering must be known by both manager 
5 and agent. This as well as supported functions are considered 
as Shared Management Knowledge . 

SW Download Management Procedures 

This section covers the download procedure for software by 
10 the Base Station from the Base Station Controller. 

Load Data Initiate 

This message is sent from the BSC to the BS to initiate the 
loading of a file. It indicates the number of segments for 
15 which a network layer acknowledgment is required (window size) . 
When receiving data the BS sends an ACK after this number of 
segments, except for the last batch. 

Load Data Segment 
20 These multi-segment messages carry the files for the 

transfer initiated by the Load Data Initiate message. No other 
file transfer is allowed until the current transfer is finished. 

The ACK is for the number of segments specified in the Load 
Data Initiate message, except that when all the expected blocks 

2 5 have been received the ACK is sent regardless, of the window 

size. If the timer for a time-out for the Layer 3 
acknowledgment expires, the BSC sends a Load Data Abort message 
and the file transfer is aborted. 

Meaning of Ack message: A window of Load data segment 

3 0 messages or a complete file has been received. 

Load Data Abort 

This message is used by either end if the file transfer can 
no longer be supported. This message will also be used by the 
3 5 BS if the received amount of data exceeds the expected amount. 

Load Data End 

This message is sent by the BSC to the BS . The BS sends an 
ACK when the file has been received in the BS . 
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Activate Request 
This message is sent by the BS when the resource presented 
by the object instance (BS manager or BS) has started up. The 
initialization of mentioned object instance is started with 
5 software activation, which may include software download 
continuing with attribute setting. 

Activate SW 

This message from the BSC to the BS activates the loaded 
10 software, indicating which file (or files) is to be activated. 

The acknowledgment of the Activate SW indicates if the software 
can be activated, or if it cannot (by use of a NACK) , The 
activation may include BS internal software distribution. 

15 SW Activated R eport 

This message from the BS to the BSC is sent from the 
addressed object on the BS at a successful completion of the 
software distribution to and activation on all indicated 
destinations in the BS . 

20 

Air Interface Management Pr ocedures 

This section covers the Base Station Controller commands 
for setting O-Interface 510 for the Base Station. 

25 Set BS Attributes 

This message is sent to the BS manager object, providing BS 
attributes related to the air interface and attributes that are 
common for all TRXs . 

3 0 Set TRX Attributes 

This message is sent for every TRX instance providing all 
the necessary attributes relating to that TRX. This message 
also includes any information that is common to all channels of 
the TRX. 



35 



Test Management Pro cedures 

This section covers the testings commands sent by the Base 
Station Controller to the Base Station. 
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Perform Test 

This message tells the BS to perform a test , if necessary 
to set a physical configuration for the BSC to carry out a test 
on the BS, or to perform a test using a particular 
5 configuration. Any measurements may be performed as specific 

tests. Duration for the test can be given, after which the test 
report may be autonomously sent if so requested. 



Two tests are defined . 
10 1. A radio loop test via the transceiver is used to test most 
of the equipment needed to provide service of one traffic 
channel. The loop starts and ends in the transceiver 
baseband parts and loops one traffic channel back inside 
the transceiver before the antenna. The baseband parts of 

15 the transceiver calculate the bit error rate to describe 

the quality of service that channel provides. This test 
can be used in conjunction with the previous test to 
discriminate the location of a possible hardware failure, 
2. BS self test is used to activate BS internal self test 

20 procedures made to test equipment that provides the 

services of a logical object . 



Test Report 

This message is sent by the BS giving the result of a test 
2 5 ordered by the BSC and is sent autonomously as soon as the 

result is available. The Test Report shall also be sent after a 
specific request from the BSC, "Send Test Report". The Test 
Report indicates what was tested, the test type, and the result. 
No Ack or Nack is returned to the BS . 

30 

Send Test Report 

This message is sent from the BSC asking for the 
result /report of a test which is not to be sent autonomously, or 
which is made continuously, in which case the present result of 
35 the test is required. The message includes identification of 
the test . 
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Stiop Test 

This message is used by the BSC to stop a continuously 
recurring test at the BS, to reset a physical test configuration 
to the normal configuration, or to stop the test and to restore 
5 to the normal physical configuration. The message includes 
identification of the test being performed. 

Performance Management Pro cedures 

This section covers the performance management procedures 
10 by the Base Station. 

Pg>rform Measurement 

This message tells the BS to perform a measurement. It 
indicates the type of measurement to be performed and the 
15 measurement reporting schedule (which corresponds to the 

measurement result 'granularity'). This procedure may be used 
for an already running measurement to modify the reporting 
schedule. 

20 Measurement Report 

This message is sent by the BS giving the results of a 
measurement ordered by the BSC. The reporting may be either 
scheduled or requested, which is indicated in the message. No 
Ack or Nack is returned to the BS . 



25 



30 



Send Measurement Results 

This procedure is used by the BSC to request a copy of the 
current results for a measurement it previously ordered. This 
procedure does not affect the measurement collection within the 
BS, nor does it affect the scheduled reporting of measurement 
results , 



Stop Measurement 

This procedure is used by the BSC to stop a measurement in 
35 the BS that it previously ordered. Any results not yet reported 
are lost . 
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State Manaqetnent and Event Report Procedures 

This section covers the reports and information provided by 
the Base Station to the Base Station Controller. 



5 Changed State Event Report 

An unsolicited report is sent from the BS to the BSC 
whenever a change of operational state of a managed object 
(defined in this specification) or of the optional manufacturer 
dependent state occurs. The message is also sent when any site 
10 input changes its state. 

A failure, causing change of operational state, shall 
generate two event reports. Change State Event Report and 
Failure Event Report. No Ack or Nack is returned to the BS . 

15 Failure Event Report 

An unsolicited report is sent from the BS to the BSC 
whenever failure events occur in the BS . Such failure events 
are : 

fault report, resulting from passing a threshold, but 
20 not constituting a failure. 

failure of a resource. There shall be a report for 
failure start and another for failure ceased. 
A failure causing change of operational state shall generate two 
event reports. Change State Event Report and Failure Event 
25 Report. No Ack or Nack is returned to the BS . 

Stop Sending Event Reports 

The inhibition of sending of event reports is used by the 
BSC to prevent a flood of event reports which are of no benefit 

30 to the BSC. One example of this occurs at a BS restart 

following a power failure. The operational capability of the BS 
hardware is unlikely to be different from what it was before the 
failure, and a flood of reports, each stating that a piece of 
hardware is operating, will delay the software download. 

35 Another example concerns the case of a frequently occurring 
transient fault. 
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Rf^st-art Sending Event Re ports 

When the BS is back in normal operation or if it is of 
interest to check whether the BTS still generates a flood of 
Event Reports a Restart Sending Event Reports should be sent. 

5 

Change Administrative State 

The Change Administrative State message is used by the BSC 
to change the administrative state for a managed object. 

10 Change Adminisf rative State Reauest 

The request message is sent by the BS when there is a need 
to change the administrative state of a managed object at the BS 
site. This message can only be initiated as a result of a local 
MMI command . 

15 

Ecruipment Manag ement Procedures 

This section covers the equipment management commands sent 
by the Base Station Controller and their response. 

20 Opstart 

This message is sent by the BSC to tell the BS to attempt 
to operate the identified object putting it to an initial normal 
operational state (i.e., "enabled"). This message does not 
affect the object's administrative state if there exists a value 
25 explicitly assigned by the BSC. If there is yet no 

administrative state value explicitly set by the BSC (e.g., at 
an initialization time) , the object shall be presumed to be 
administratively locked by default. No BS function is 
responsible for testing the operability of the identified 
30 resource as a consequence of this message. Prior to this 
message being issued, all necessary physical and logical 
preparations (such as repair of equipment, software downloading, 
parameter setting, etc., as needed) are expected to have been 
completed. If the object is in fact not ready to be in an 
35 enabled state, the object will be in a fault condition as a 

consequence of this message, and the condition shall be handled 
by the object's usual fault handling function as the condition 
is detected. 
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Reinitialize 

This message is sent by the BSC to tell the BS to have 
specified resource of the indicated object start a re- 
initialization procedure. 

5 

Set Site Outputs 

This message is sent by the BSC to tell the BS to set 
specified site outputs to the specified state. 

10 Miscellaneous Procedures 

This section outlines additional procedures requested by 
the Base Station Controller. 



Get Attributes 

15 This message is used by the BSC to tell the BS to send 

attributes which have previously been set by the BS . It may be 
used as a check on accuracy and be incorporated into normal 
procedures, or may be used by the BSC to recover information 
which it has lost, in the absence of the OMC. 

20 

Set Alarm Threshold 

This message is used by the BSC to tell the BS some 
threshold parameters related to fault thresholds. 

2 5 Message Categories 

This section defines the transport format and coding of the 
two Network. Management message categories sent over the NOTES 
OAM&P interface. The various message categories may be sent in 
either direction. In each message, the message discriminator 

30 identifies the category and is transmitted first. In a message 
the octets are sent in the order shown in the description of . the 
messages. In an octet bit 1 is transmitted first. 

In the following sub- sections M and 0 denote whether 
information elements are mandatory or optional. 

35 



JSDOCID: <WO 9713353A1_L> 



wo 97/13353 



PCTAJS96/15I90 



175 



Formatr.ed Q&M messages 



10 



15 



20 



INFORMATION ELEMENT 


M/O 1 LENGTH 


CODING 


Message Discriminator 


M 


1 


10000000 


Placement Indicator 


M 


1 


Note 1 


Sequence Number 


M 


1 


Note 2 


Length Indicator 


M 


1 


Binary, Note 3 


OScM Data Field 


M 


V 


Note 4 



Note 1: The meanings and codings of the Placement Indicator 
are : 

Only: This message is contained within one segment: 10000000 

First: The first segment of a multi-segment message: 
01000000 

Middle: A middle segment of a mult i -segment message: 00100000 
Last: The last segment of a mult i- segment message: 00010000 

Note 2: This is the sequence number of the segment in the 

message, modulo 256. starting with 00000000. Thus a 
single segment message is here coded 00000000, but 
this does not inhibit the use of this code in long 
multi -segment messages. 
Note 3: The Length Indicator gives the length of the O&M data 
field which is less than or equal to 255 octets. This 
length indicator should not be confused with attribute 
25 value length indicator described in Section 6.2. 

Note 4 : coding for O&M Data field is found in Section and 

following subsections. 
Manufacturer-Defined O&M me ssages 

Messages of this format are not currently used, and are 
30 reserved for future used. 



35 
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10 



15 



20 



25 



INFORMATION ELEMENT 


M/U 


Jbr^iMCj i H 


8 1 


Message Discriminator 


M 


1 


00010000 


Placement Indicator 


M 


1 


Note 1 


Sequence Number 


M 


1 


Note 2 


Length Indicator 


M 


1 


Binary, Note 3 


Manici Lengcn -Lnaxcdu^x 


M 


1 


Binary, Note 4 


Manuf . Identifier 


M 


V 


Note 5 


Man-Defendant O&M Data 
Field 


M 




Proprietary 



30 



Note 1: The meanings and codings of the Placement Indicator 
are : 

Only: This message is contained within one segment: 10000000 

First: The first segment of a multi-segment message: 
010000000 

Middle: A middle segment of a multi-segment message: 00100000 
Last: The last segment of a multi-segment message: 00010000 

Note 2: This is the sequence number of the segment in the 

message, modulo 256, starting with 00000000. Thus a 

single segment message is here coded 00000000, but 

this does not inhibit the use of this code in long 

mult i- segment messages. 
Note 3: The Length Indicator gives the length of the 

Manufacturer-defined O&M data field which is less than 

or equal to 255 octets. 
Note 4: The Length Indicator gives the length of the 

Manufacturer Identifier field which is less than or 

equal to 255 octets. 
Note 5: The Manufacturer Identifier is an octet string of 

maximally 255 octets. 



MMI Transfer 

The message formats for MMI transfer are defined here for 
future use, and are not currently used. 

35 
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10 



15 



20 



25 



30 



35 



TMcrM?M2iTTnN ELEMENT 


M/O 


LENGTH 


CODING 

8 1 


Message Discriminator 


M 


1 


01000000 


Placement Indicator 


M 


1 


Note 1 of Sec. 5.1.1 


Sequence Numtoe r 


M 


1 


Note 2 of Sec . 5.1.1 


Length Indicator 


M 


1 


Binary, Note 1 


MMI Data Field 


M 


V 


for future use 



Note 1: The Length Indicator gives the length of the MMI data 
field, which is less than or equal to 255 octets. 

Stiructu-rf? of Formatte d O&M Messages 

This section provides details of all the messages. In every 
case when particular header octets provide no usable information 
at the receiver, they are coded all I's. 

The header fields of formatted O&M messages are always 
mandatory. The attributes defined for a certain message 
supported by the BTS implementation are mandatory to be used if 
not stated otherwise in an explanatory note. 

Message types are identified in the first octet of the 
formatted O&M messages. Some messages are replied by a 
Response, an ACK or a NACK. These replies are distinguished by 
different codings of the message type (the first octet of 
formatted OScM messages) . 

ACK messages return all the attributes in the original 
message. NACK messages add two octets (one for an attribute 
identifier and one for a cause) at the end of the message. 

None of the messages concerned requires all of the capacity 
available in a Layer 2 segment, so the NACK message will not 
need a second Layer 2 frame. 

An ACK to a number of 'Load Data Segment's only consists of 
the header with the 'Load Data Segment Ack' message type. 

All attributes overwrite those defined in an earlier 
message since start-up or the last restart. Optional attributes 
provide new information if they have not been defined in an 
earlier message. 
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The message type 1 byte, object class 1 byte, and object 
instance 3 bytes are all included in each message header. 

The Object Class information element shall be filled in 
with the correct information in accordance with this 
specification. 

The Object Instance information element contains two useful 
fields : 

TRX number that identifies the TRX in a multi-TRX BS . 

Timeslot number that identifies the Channel within a 
particular TRX. 

The FORMAT field describes the structure of each 
information element using T (Tag) , L (Length) and V (Value) 
coding. T is the attribute identifier. V is the actual 
information presented. L is indicated if the information 
element is of variable length and its prediction is not possible 
in the context. Length binary-represents in a two octet space 
the number of octets in the remaining part of information 
element . 



SW Download Management Messages 
Load Data Initiate 

The load data initiate message includes the header, a 
description of the software at least 3 bytes long, and a window 
size 2 bytes long. 

Load Data Segment 

The load data segment message includes the header and the 
file data segment that is to be transferred which is at least 3 
bytes long . 

Load Data j^ort 

The load data abort message includes the header and the 
abort message . 

Load Data End 

The load data end message includes the header and the 
description of the software which is the same as the description 
of the software in the load data initiate message. 



97133S3A1.I_> 



10 



wo 97/13353 PCT/US96/15190 

179 

Activ ^f*^ Request 
The software activate request message includes the header, 
the hardware configuration at least 3 bytes and the software 
configuration which is also at least 3 bytes. 

Activate SW 

The activate software message includes the header and the 
software description of at least 3 bytes. Software Descriptions 
may be repeated for multiple software activation. No software 
description entry implies all software for the object instance. 



15 



20 



qw Activat -p^d Report 

The software activated report message includes the header 
and the acknowledgment of activation. 

z^i-r Tnter-Fane Man agement Messages 
gf^t- BS Attributes 

The set Base Station attributes message includes the 
header, BSC ID (3 bytes), BS ID (3 bytes), LAC (3 bytes), MCC (3 
bytes) , MNC (3 bytes) , BS capabilities (5 bytes) . system type 
(2 bytes), service provider 2 bytes, BS TX Power Maximum (2 
bytes, power control size (2 bytes), RX mode (2 bytes), TX mode 
(2 bytes) , and HO information (Desired Length) . 

25 Set TRX Attributes 

The set TRX attributes message includes the header. Radio 
Channel ID (2 bytes). PN code (2 bytes), MAX bandwidth (2 
bytes) , and MIN bandwidth (2 bytes) . 

30 Test Management Mes sages 
Perform Test 

The perform test message includes the header. Test Number 
(2 bytes) . Autonomously Report request (2 bytes) , Test Duration 
(3 bytes) . and the physical configuration during testing (at 
3 5 least 2 bytes) . Use of Physical Configuration depends on the 
need on extra information in setting up specific test 
configurations . 
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10 



Test Report 

The test report message includes the header, the test number 
performed (2 bytes) , and test report information (at least 3 
bytes) , The test report information may give a numerical result 
or an indication of the range into which the test report falls. 

.Qend Test Report 

The send test report message includes the header and test 
number (2 bytes) , 

Stop Test 

The stop test message includes the header and the test number to 
be stopped (2 bytes) . 

15 Perform Measurement 

The perform measurement message includes the header, 
measurement type (1 byte), and the reporting schedule (1 byte). 

Measurement Report 
20 The measurement report message includes the header, 

measurement type (1 byte) , reporting reason (1 byte) , and 
measurement results (at least 3 bytes) . 

Send Measurement Results 
25 The send measurement results message includes the header 

and the measurement type (1 byte) . 

Stop Measurement 

The stop measurement message includes the header and the 
3 0 measurement type to be stopped (1 byte) . 

State Management and Event Report Messages 

Changed State Event Report 
The changed state event report message includes the header, 
35 operational state (2 bytes) , availability status (at least 3 
bytes) , and the site input (at least 3 bytes) . 
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Failure F.vent Report 

The failure report event message includes the header, event 
type (2 bytes), perceived severity (2 bytes), probable cause (4 
bytes) , the hardware description (at least 3 bytes) , the 
software description (at least 2 bytes) , and additional 
information (generally greater then 2 bytes) . Depending on the 
nature of the specific failure and the BS implementation, only 
the needed/supported attributes shall be sent. These fields 
shall be included to identify the specific associated equipment 
or software in case the addressed functional object alone is not 
sufficient to localize the failure. 

stop Sending F .vent Reports 

The stop sending event reports message includes the header, 
operational state (2 bytes) , availability status (at least 3 
bytes) , and the probable cause (4 bytes) . Stop Sending Event 
Reports concerning events with any of the parameter values in 
this attribute list. Depending on the type of event report that 
shall be stopped, one of the attributes shall be sent. 



R<qatart Sending E vent Reports 

The restart sending event reports message includes the 
header, operational state (2 bytes) , the availability status (at 
least 3 bytes) , and the probable cause (4 bytes) . Restart 
25 sending Event Reports concerning events with, any of the 

parameter values in this attribute list. Depending on the type 
of event report that shall be restarted, one of the attributes 
shall be sent. 

30 Change A.dminisf rative State 

The change administrative state message includes the header 
and the new administrative state (2 bytes) . 



rhanaf> Administrat ive State Request 

The administrative state request message includes the 
header and the requested administrative state for the object (2 
bytes) . 
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Equipment Management Messages 
Qpstart 

The opstart message includes the message header which 
signifies that operation is to begin. 

5 

Rf^.initialize 

The reinitialize message includes the header and the 
hardware to be reinitialized (at least 3 bytes) . HW 
Descriptions may be repeated for multiple resources. If no HW 
10 Description is provided, all resource for the objects is 

implied. For a software reinitialization. Activate SW message 
shall be used. 

fiet Site Outputs 

The set site outputs message includes the header and the 
site outputs (at least 3 bytes) . 

net Attributes 

The get attributes message includes the header and the list 
20 of required attributes (att least 3 bytes) . 

Set Alarm Threshold 

The set alarm threshold message includes the header, 
probable cause (4 bytes), and additional required information. 

25 

Coding 

This Section defines the coding of each field in the 
messages defined in earlier Sections. 

The following conventions are assumed. The least 
30 significant bit is transmitted first, followed by bits 2, 3, 4, 
etc. In an element, octets are identified by number. 
Octet 1 is transmitted first, then octet 2, etc. Further: 

When a field extends over more than one octet, the order of 
bit values progressively decreases as the octet number 
35 increases. The least significant bit of the field is 

represented by the lowest numbered bit of the highest 
numbered octet of the field. 

For unpredictable variable length elements, a length 
indication coding method shall be used. Always the Tenth 



JSDOCID: <WO 97l3353A1„t_> 



wo 97/13353 PCT/US96/1S190 

183 

information indicates the number of element units (which is 
octets) following the length indicator. 

All used values are indicated. Other values are reserved. 

5 Message Type 

The Message Type is coded with 1 octet. 

The message types used are described above. 

10 Ob ject Class 

An Object Class is coded with 1 octet. The values of the 
object class code are as defined below: 



Object Class 
15 Base Station Manager 

Base Station 

02 



20 



25 



30 



hexadecimal code 
00 



03 



Transceiver 
Channel 

<reserved for future use> < 04-FE> 

NULL 

Obi ect Instance 

The Object Instance is coded with 3 octets, addressing the 
specific object of the given object class as illustrated below: 



NULL 



Transceiver number 



Timeslot number 



1 

2 
3 



These three octets are mandatory in the header of every 
message. The NULL byte is reserved for future use (in case of 
changes to information model), and is coded NULL. 

The Transceiver number distinguishes TRXs at a site under 
the Base Station. The Timeslot number distinguishes channels 
under the TRX. 

35 When the object class is BS Manager all the octets are 

NULL, as there is only one BS manager. When the object class is 
BS all the octets are NULL, as there is only one BS . 
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15 



When the object class is TRX, octet 2 is a binary pre- 
sentation of the number of the addressed TRX Octet 3 is coded 
NULL. If the TRX number is NULL, it shall be understood to 
refer to all TRXs under the BS . 

When the object class is Channel, octet 3 is a binary 
presentation of the number of the addressed Timeslot, and octet 
2 is the number of the TRX above the addressed Channel. If the 
Timeslot number is NULL, it shall be understood as referring to 
all Channels under the TRX. 

To avoid unnecessary complexity of BS implementation, it 
shall not be allowed to assign a NULL value for the TRX number 
in the case that the Channel object class is addressed (without 
this constraint, this could be understood as referring to a 
particular channel of all TRXs) . The value for NULL is <FF> in 
all the cases mentioned above in this Section. 



Attributes and Parameters 

The Attribute Identifier is coded with 1 octet. The number 
of parameters within an attribute I at least one. The length of 
20 the parameters within an attribute will vary. 

The data structures of the attributes and parameters are 
described in the remaining part of this section in tabular forms 
with no formal text description of the individual subsections 
provided because of their self-explanatory nature 
25 Henceforth "Attribute Identifier" in this section means the 

identifier for an attribute or a parameter . 



30 



Additional Text 



Attribute Identifier 



Length 



Additional Text 



(cont . ) 



(cont . ) 



1 

2-3 
4 

N 



3 5 'Additional Text' is ASCII coded diagnostic or debug 

information that will not be interpreted by the system (or the 
operator) but may help engineers to more precisely identify 
failure causes. 
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185 



Attribute Identifier 



Administrative State 



Attribute Identifier 



Autonomously Report 



Autonomously Report 

Autonomously Report 
Not Autonomously Report 



Administrative State is coded as follows: 
Locked 
Unlocked 
Shutting Dovm 

NULL (Adm, State not supported) FF 
Autonomously Report 



01 
00 
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20 



25 



30 



AvailabT 1 •jty Status 



Attribute Identifier 



Length 



Availability Status 



(cont . ) 



(cont . ) 



1 

2-3 
4 

N 



35 



Availability Status may contain one or more octets. Each 
octet has a single status value, which is coded as follows: 
In test 
Failed 
Power off 2 
Off line 
<not used> 
Dependency 
Degraded 
Not installed 



0 
1 

3 
4 
5 
6 
7 
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Attribute Identifier 



Facility 



(cont . ) 



(cont . ) 



(cont . ) 



1 
2 
3 
4 
5 



^BS capabilities' defines the services being offered by the 
BS coded as bit-map of 32 bits. 



25 



R.q Identity 



At t r ibu t e Identifier 



Base Station Identity 



(cont . ) 



(cont . ) 



(cont . ) 



1 
2 
3 
4 
5 



Base Station Identity <32 bits> where the low order bit is 
bit 1 octet 2 and the high order bit is bit 8 octet 5. 



BS maxiinum TX power 



Attribute Identifier 



BS max TX power 



1 
2 



BS max TX power at antenna input <dBm or dBw> 



30 



BSC Identity 



Attribute Identifier 



BSC Identity 



(cont . ) 



1 
2 

3 



BSC identity <16 bits> where the low order bit is bit 1 of 
octet 2 and the high order bit is bit 8 of octet 3 . 



35 
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P.vent Tvx>e 

Attribute Identifier 
Event Type 



5 Event Type 

communication failure 
quality of service failure 
processing failure 
equipment failure 
10 environment failure 

<reserved for future use> 



00 
01 
02 
03 
04 

<05-FF> 



15 



20 



File Data 



Attribute Identifier 



Length 



File Data 



( cont . ) 



(cont . ) 



1 

2-3 
4 

N 



The coding of 'File data' is not defined in this 
specification . 



25 



File Id 



Attribute Identifier 



Length 



File Id 



(cont . ) 



(cont . ) 



1 

2-3 
4 

N 



30 



35 



File Version 



Attribute Identifier 



Length 



File Version 
(cont . ) 
(cont . ) 



1 

2-3 
4 

N 
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Attribute Identifier 



Length 



HW Description 1 



HW Description n 



1 

2-3 
4 

N 



HW Configuration contains a list of HW Descriptions related 
to a managed object. 



HW Description 



Attribute 


Identifier 


Equipment 


Id Length 


Equipment 


Id 


(cont . ) 


Equipment 


Type Length 


Equipment 


Type 


(cont . ) 


Equipment 


Version Length 


Equipment 


Version 


(cont . ) 


Location 


Length 


Location 


( cont . ) 



1 

2-3 



All fields are variable length ASCII character strings 
The coding of these fields will not be defined in this 
specification . 



30 



LAC 



Attribute Identifier 
Location Area Code 



1 

2 



35 
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T.isti of Re quire d Attributes 



Attribute Identifier 



Length 



Attribute Id, 



(cont . ) 



(cont . ) 



Each Attribute Id is one octet 



PCT/US96/15190 



1 

2-3 
4 

N 



10 



15 



Maximum bandwidth 



Attribute Identifier 



Multiple Timeslot Limit j 2 



^Multiple timeslot Limit' indicates the maximum number of 
TDMA timeslots (of the same frame) that can be assigned to a 
bearer channel (coded <1. .16>) . 



20 



25 



30 



35 



Maximum M.q powe r reduction 



Attribute Identifier 



Max MS power reduction 



MCC 



Attribute Identifier 



Mobile Colour Code 



Measurement Results 



Attribute Identifier 



Length 



Measurement results 



(cont . ) 



(cont . ) 



1 
1 



1 
2 



1 

2-3 
4 



N 



Measurement results <binary coded decimal value with 
meaning determined by measurement type. 
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MNC 



Attribute Identifier 



Measurement Type 



Attribute Identifier 



Mobile Network Code 
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10 



15 



Minimum Bandwidth 



Attribute Identifier 



Sub-Multiple Timeslot Limit 



'Sub-Multiple Timeslot Limit' indicates the maximum 
separation (between frames) of TDMA timeslots that can be 
assigned to a bearer channel (coded <1..25>) . 



Nack Causes 



20 



25 



30 



35 



Attribute Identifier 



NACK Cause 



1 
2 



Nack Causes 

General Nack Causes: 

Incorrect message structure 

Invalid message type value 

Invalid Object class value 

Object class not supported 

Object Instance unknown 

Invalid attribute identifier value 

Attribute identifier not supported 

Parameter value outside permitted range 

Inconsistency in attribute list 

Specified implementation not supported OA 

Message cannot be performed 

<reserved> 

Specific Nack Causes: 

Resource not implemented 
Resource not available 



01 
02 
03 
04 
05 
06 
07 
08 
09 

OB 

<OC-l F> 

20 
21 
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20 



Frequency not available 22 
Test not supported 2 3 

Capacity restrictions 24 
Physical configuration cannot be performed 25 
Test not initiated 

Physical configuration cannot be restored 
No such test 
Test cannot be stopped 

Message inconsistent with physical config 
Complete file not received 
File not available at destination 
File cannot be activated 
Request not granted 
Wait 

Measurement not supported 
Measurement not initiated 
No such measurement 
Measurement cannot be stopped 
<reserved> 
NULL 



26 
27 
28 
29 
2A 
2B 
2C 
20 
2E 
2F 
30 
31 
32 
33 

<34-FE> 
FF 



Conflicting or incomplete data in the attribute list which 
prevents the BS from performing the message (for 08) . This Nack 
cause applies when the message is valid and is supported by the 
25 BS, but cannot be performed correctly for reasons not covered by 
other general or special Nack causes (09) . Data in attribute 
list is valid, but beyond the capabilities of the particular BS 
implementation (30) . 



30 



35 



NOTES Channel 



Attribute Identifier 



BS Port Number 



Times lot Number 



Subs lot Numbe r 



BS Port Number 



<0-FF> 
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Timeslot Number 

Time slot in transmission 

link 
Subs lot Number 

a (bits 1,2) 

b (bits 3,4) 

c (bits 5,6) 

d (bits 7,8) 

64 kbps signaling FF 

Operational State 



Attribute Identifier 



Operational State 



1 
2 



PCT/US96/S5B90 



<0-lF> 

00 
01 
02 
03 



15 Operational State 

Disabled 01 

Enabled 02 
These states are in accordance with ISO/CCITT values 
(X. 721) 

20 <reserved for future use> <03-FE> 

NULL (Operate. State not supported) FF 



25 



30 



35 



Perceived Severity 



Attribute Identifier 



Severity Value 



Severity Value 

failure ceased 
critical failure 
major failure 
minor failure 
warning level failure 
indeterminate failure 
<reserved> 

PN Code 



01 
02 
03 
04 



Attribute Identifier 



PN code ( 0 . . 7 ) 



1 
2 



00 



05 

<06-3F> 



1 
2 
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Attribute Identifier 



Power control step size 



Probable Cause 





Attribute Identifier 


Probable Cause Type 


Probable Cause Value 


Probable Cause Value 


( cont . ) 


Probable Cause 


Type 




ISO/CCITT 


values (X.721) 


01 


GSM specific values 


02 


Omnipoint 


specific values 


03 


<reserved 


for future use> 


<04-FF> 


Probable Cause 


Value 




When Probable Cause Type is 01, 


02 or 03 


value of the object identifier 


value spe 



1 

2 
3 
4 



syntax coding is used, 
Physical Confia 



Attribute Identifier 



Length 



Required Test Config 



( cont . ) 



(cont . ) 



1 

2-3 
4 

N 



Radio channel ID 



Attribute Identifier 



Radio channel ID (hex coded) 



1 
2 



Reporting Reason 



Attribute Identifier 



Reporting Reason 
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Reporting Reason 

Scheduled Reporting 
Requested reporting 



0 
1 



10 



15 



20 



Reporting Schedule 



Attribute Identifier 



Reporting Schedule 



Reporting Schedule <5,15,30,60> minutes 



RX Mode 



Attribute Identifier 



RX Mode (interference/noise limited) 



Servicf^ Provider 



Attribute Identifier 



Service Provider 



(cont . ) 



* Service Provider' is coded on 32 bits with Low order bit 
being 1 octet 2 and high order bit being bit 8 octet 3. 



25 



Site Inputs 

If Site Inputs are requested from BS Manager with message 
Get Attributes, all inputs are listed. 



30 



35 



Attribute Identifier 



Length 



Site Input 



( cont , ) 



(cont . ) 



1 

2-3 
4 

N 



Each octet from 4 to N controls one Site input . Each of 
these octets contain the input number and the status of the 
input and they are coded as follows: 



^JSDOCID: <WO 9713353A1_L> 



wo 97/13353 



195 



PCT/US96/15190 



8 7 6 5 4 3 2 1 

] State I Input number ] ] 

State is a binary presentation of the input state, 0 or 1 . 
Input number is a binary presentation of input number, {the use 
of Site Inputs is tbd} 

.qire Outputs 

If Site Outputs are requested from BS Manager with message 
Get Attributes, all outputs are listed. Coding of this 
information element is the same as in Site Inputs. 



15 



Attribute Identifier 


1 


Length 


2-3 


Site Output 


4 


(cont . ) 




(cont . ) 


N 



20 



25 



SW Configuration 



Attribute Identifier 



Length 



SW Description 1 



SW Description n 



1 

2-3 
4 

N 



SW Conf . contains a list of SW Descriptions related to the 
managed object. 



30 



SW Description 



Attribute Identifier 
File Id 
File Version 



1 
2 
N 



35 
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Attribute Identifier 



System Type 
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System type 

0 DCS1900 cause codes 

1 Bellcore Generic C Cause Codes 
2-255 Reserved 



10 



15 



20 



TEI 



Attribute Identifier 



TEI 



TEI <0 . . 63> 



TP>c;t Duration 



Attribute Identifier 



Test Duration 



1 

2-3 



Test Duration <01-FFFF> 

Test Duration is a binary presentation of seconds indicating the 
time the test should last . 



25 



30 



Test No 



Attribute Identifier 



Test Number 



1 
2 



Test Number 
<not used> 

Radio loop test via transceiver 
BS self test 



00 
01 
02 



35 
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Attribute Ident if ier 



Length 



Test Result Info 



(cont . ) 



(cont . ) 



TX Mode 



Attribute Identifier 



TX Mode (Linear/non- linear) 



Window Size 



Attribute Identifier 



Window Size 



PCT/US96/15I90 



1 

2-3 
4 

N 



1 

2 



Window Size is a binary presentation of the number of layer 
3 Load Data Segments to be sent before a layer 3 acknowledgment. 
Value 0 is not used. 



2 0 PCS2000 Privacy & Authentication Require ments 

This section sets forth the general requirements for PCS 
Privacy and Authentication, (P 6c A) for the PCS2000 Air 
Interface system to the DCS-1900 and, alternatively, to the 
Bellcore Generic C/ISDN based network architectures. The need 

25 for privacy and authentication is based on the use of radio 

transmission for access to communication services. The radio 
transmission access or air interface is particularly sensitive 
to the use of PCS services by unauthorized users and 
eavesdropping on voice and data information which is exchanged 

30 over the air interface. Since wireless access intrinsically 
does not provide for the same level of protection to their 
service operators and users as the traditional public and 
private wireline telecommunication networks, additional security 
features are required to protect access to the PCS services 

35 offered by sei-vice providers the privacy of the user's voice, 
data, or other information 
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Common Requirements 
ITIM - AC Authentication 

The permanent data required for authenticating the user 
shall be stored in the Authentication Center (AC) and in the 
5 User Identity Module (UIM) . 



10 



35 



Fraud Protection 

The authentication process shall protect against attempts to 
obtain service illegally. This includes interception of call 
information, take-over attacks and "cloning". Protection shall 
be upgradeable for the life of the system. 



Forward Compat ibi 1 it v 
PCS2000 PficA functionality shall be both upgradeable and 
15 forward compatible for the life of the system. 

Protection of Sec ret Data 

No user or service provider secrets, either permanent or 
temporary, shall be allowed to pass unencrypted over the radio 
20 channel . 

Radio Channel Protection From Exte rnal Manipulation 
PCS2000 radio channels shall be protected from external 
malicious signaling manipulation. 

25 

User Simplicity & Transp arency 

From the user prospective, the PCS2000 P&A processes shall 
be virtually transparent. The user shall incur a minimum of 
inconvenience and the wireless calling process shall be no more 
30 complicated than the conventional wireline process. 

Low Complexity 

PCS2000 P&A shall add minimum complexity to the MS and to 



the network . 

Registration & Call Set-u p Time Impacts 

The PCS2000 P&A process shall add a minimum amount of time 
to the call set-up time. 



MSDOCID: <WO 97133S3A1_L> 



wo 97/13353 



199 



PCT/US96/15190 



Rrror Tolerance 

The PCS2000 PficA processes shall be robust to noise and 
interference . 

5 Two Way Authe ntication 

In addition to authenticating the user to the provider's 

network, the service provider's network shall be optionally 
authenticatable to the MS. 

10 Bus ines^^- Friendly 

The PCS2000 PScA processes shall be amenable to an 
unregulated competitive business environment. A minimum amount 
of trust and interworking arrangements are desirable in order to 
let service providers serve each others roamers with a minimum 

15 of concern and perceived monetary risk an a maximum degree of 
mutual advantage. 

GSM Based Privacy and Aut hentication 
Introduction 

20 All security functions must be implemented with minimum 

assumptions about the cryptological algorithms that are used, 
and it must be possible to change these algorithms during the 
system life time. Any change in these algorithms must not 
change the format of the messages exchanged via the interfaces 

25 of the system. The system must be prepared for parallel 

operation of more than one algorithm during a transitional 
period. 

The security procedures must includes mechanisms to enable 
recovery in event of signaling failures. These recovery 
3 0 procedures must be designed in such a way that they cannot be 
used to breach the security of the system. 

Security Features 

The security features described in the following provide a 
35 level of protection at the radiopath that is at least as good as 

the level of protection provided in the fixed networks. 
The following security features are considered: 
user identity (IMSI) confidentiality; 
user identity (IMSI ) authentication; 
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user data confidentiality on physical connections; 
signaling information element confidentiality. 
The implementation of these four security features is mandatory 
on both the fixed infrastructure side and the MS side. This 
5 means that all PCS2000 networks and all MSs shall be able to 
support every security feature. Use of these four security 
features is at the discretion of the operator for its ovm 
subscribers while on the home network. For roaming subscribers, 
use of these four security features is mandatory unless 
10 otherwise agreed by all the affected PCN operators. 

User identity confide ntiality 
The user identity confidentiality feature is the property 
that the IMSI is not made available or disclosed to unauthorized 
15 individuals, entities or processes. 

This feature provides for the privacy of the identities of 
the users who are using PCS resources (e.g. a traffic channel or 
any signaling means) . It allows for the improvement of all 
other security features (e.g. user data confidentiality) and 
20 provides for the protection against tracing the location of a 

mobile user by listening to the signaling exchanges on the radio 
path . 

This feature necessitates the confidentiality of the user 
identity (IMSI) when it is transferred in signaling messages 
25 together with specific measures to preclude the possibility to 
derive it indirectly from listening to specific information, 
such as addresses, at the radiopath. 

The means used to identify a mobile user on the radiopath 
consists in a local number called TMSI (Temporary Mobile 

30 Subscriber Identity) . 

When used, the user identity confidentiality feature shall 
apply for all signaling sequences on the radiopath. However, in 
the case of location register failure, or in case the MS has no 
TMSJ available, open identification is allowed on the radio 
3 5 path. 

TTgf»-r identity authent ication 
International Mobile Subscriber Identity (IMSI) 
authentication is the corroboration by the land-based part of 
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the system that the user identity (IMSI or TMSI), transferred by 
the mobile user within the identification procedure at the 
radiopath, is the one claimed. 

The purpose of this security feature is to protect the 
5 network against unauthorized use. It also provides for the 
protection of the PCS users by denying the possibility for 
intruders to impersonate authorized users. 

The authentication of the PCS user identity may be triggered 
by the network when the user applies for: 
-^Q •a change of a subscriber-related information element in the 
VLR or HLR (including some or all of location updating 
involving change of VL.R, registration or erasure of a 
supplementary service) , or 

• an access to a service (including some or all of: set-up of 
15 mobile originating or terminated calls, activation or 

deactivation of a supplementary service) , or 

• first network access after restart of MSC/VLR, 

• or in the event of cipher key sequence number mismatch. 
Physical security means must be provided to preclude the 

20 possibility to obtain sufficient information to impersonate or 
duplicate a user of PCS, in particular by deriving sensitive 
information from the mobile station equipment. 

When the user identity authentication procedure fails on an 
access request to the PCS, and this failure is not due to 
25 network malfunction, the access to the PCS shall be denied to 
the requesting party. 

Authentication during a malfunction of the network: 

• Calls are permitted (including continuation and hand-over) 
when an MS is registered and has been successfully 

30 authenticated, whether active or not active on a call. 

• Calls are permitted when an MS has already been registered 
(and therefore been already authenticated) and can not be 
successfully reauthenticated due to the network malfunction 
(e.g. the Home PCS was not able to provide authentication 

35 pairs RAND, SRES) . 

• Calls are not permitted when an MS attempts to register and 
can not be successfully authenticated due to the network 
malfunction . 
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o A new registration needs to be performed when the MS is not 
registered, or ceases to be registered, and the preceding 
cases apply. 

5 User data confidentiality on physical c onnections 

(voice and non-voice) 

The user data confidentiality feature on physical 
connections is the property that the user information exchanged 
10 on traffic channels is not made available or disclosed to 
unauthorized individuals, entities or processes. 

The purpose of this feature is to ensure the privacy of the 
user information on traffic channels. 

Encryption will normally be applied to all voice and non- 
15 voice communications. Although a standard algorithm will 

normally be employed, it is permissible for the mobile station 
and/or PCS infrastructure to support more than one algorithm. 
The infrastructure is responsible for deciding which algorithm 
to use {including the possibility not to use encryption, in 
20 which case confidentiality is not supported) . 

When necessary, the MS shall signal to the network 
indicating which of up to seven encryption algorithm, plus one 
transparent algorithm, it supports. (Note: The effect of the 
"transparent algorithm" being selected is the same as not being 
25 encrypted.) The serving network then selects one of these that 
it can support (based on an order of priority preset in the 
network), and signals this to the MS. The selected algorithm is 
then used by the MS and by the network. 

3 0 Signaling information element c onfidentiality 

The signaling information element confidentiality feature is 
the property that a given piece of signaling information which 
is exchanged between mobile stations and base stations is not 
made available or disclosed to unauthorized individuals, 
35 entities or processes. 

The purpose of this feature is to ensure the privacy of user 
related signaling elements. 

When used, this feature applies on selected fields of 
signaling messages which are exchanged between mobile stations 
40 and base stations. 



gSDOCID: <WO 9713353A1_I_> 



wo 97/13353 PCT/US96/15190 

203 

The signaling information elements included in the message 
used to establish the connection (protocol discriminator, 
connection reference, message type and mobile station identity 
(IMSI, TMSI or IMEI according to the circumstance)) are not 
5 protected. 

The following signaling information elements related to the 
user are protected whenever used after connection establishment: 

• International Mobile Equipment Identity (IMEI), 

• International Mobile Subscriber Identity (IMSI), 

10 • Calling user directory number (mobile terminating alls) and 

• Called user directory number (mobile originated calls) . 
The IMEI requires physical protection against being removed, 
replaced or its contents being changed by unauthorized 
individuals. The IMSI is stored securely within the UIM. 

15 

User identitv confide ntiality 
The purpose of this function is to avoid the possibility for 
an intruder to identify which user is using a given resource on 
the radio path (e.g. Traffic Channel or signaling resources) by 
20 listening to the signaling exchanges on the radio path. This 
allows both a high level of confidentiality for user data and 
signaling . 

The provision of this function implies that the IMSI 
(International Mobile Subscriber Identity), or any information 
25 allowing a listener to derive the IMSI easily, should normally 

not be transmitted in clear text in any signaling message on the 
radio path. 

Consequently, to obtain the required level of protection, it 

is necessary that: 
30 • A protected identifying method is normally used instead of 
the IMSI on the radio path. 

• The IMSI is normally not used as an addressing means on the 
radio path. 

• When the signaling procedures permit it, signaling 

35 information elements that convey information about the 

mobile user identity must be encrypted for transmission on 
the radio path. 

The identifying method is specified in the following. 
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I dent i f vina method 
The means used to identify a mobile user on the radio path 
consists in a TMSI (Temporary Mobile Subscriber Identity) . This 
TMSI is a local number, having a meaning only in a given 
5 location area, the TMSI must be accompanied by the LAI (Location 

Area Identification) to avoid ambiguities. The maximum length 
and guidance for defining the format of a TMSI are specified in 
GSM 03 .03 . 

The network (e.g. a VLR) manages suitable data bases to keep 
10 the relation between TMSls and IMSIs. When a TMSI is received 
with an LAI that does not correspond to the current VLR, the 
IMSI of the MS must be requested from the VLR in charge of the 
indicated location area if its address is known; otherwise the 
IMSI is requested from the MS. 
15 A new TMSI must be allocated at least in each location 

updating procedure. The allocation of a new TMSI corresponds 
implicitly for the MS to the de -allocation of the previous one. 
In the fixed part of the network, the cancellation of the record 
for an MS in a VLR implies the de-allocation of the 
2 0 corresponding TMSI. 

To cope with some malfunctioning, e.g. arising from a 
software failure, the fixed part of the network can require the 
identification of the MS in the clear. This procedure is a 
breach in the provision of the service, and should be used only 

2 5 when necessary. 

When a new TMSI is allocated to an MS, it is transmitted to 
the MS in an encrypted mode. The MS must store its current TMSI 
in a non volatile memory, together with the LAI, so that these 
data are not lost when the MS is switched-of f . 

30 

Procedures 

This section presents the procedures, or elements of 
procedures, pertaining to the management of TMSIs. 

3 5 Location updating in the same MSG area 

This procedure is part of the location updating procedure 
which takes place when the original location area and the new 
location area depend on the same MSG. The part of this 
procedure relative to TMSI management is reduced to a TMSI re- 
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allocation (from TMSIo with "o" for "old" to TMSIn with "n" for 
"new") . The MS sends TMSIo as an identifying field at the 
beginning of the location updating procedure. 

5 Signaling Functionalities : 

Management of means for new encryption : 
The MS and MSC/VLR agree on means for encryption of 
signaling information elements, in particular to transmit TMSln. 

0 Location updating in a new MSCs area, within the same VLR 

area 

This procedure is part of the location updating procedure 
which takes place when the original location area and the new 
.5 location area depend on different MSCs, on the same VLR. From a 
security point of view, the order of the procedures is 
irrelevant . 



Signaling functionalities : 
20 Location Updating: 

The MSC/VLR indicates that the location of the MS must be 

updated . 

Location updating in a new VLR; old VLR reachable 
25 This procedure is part of the normal location updating 

procedure, using TMSI and LAI, when the original location area 
and the new location area depend on different VLRs . 

The MS is still registered in VLRo ("o" for old or original) 
and requests registration in VLRn ("n" for new) . LAI and TMSIo 
30 are sent by MS as identifying fields during the location 
updating procedure. 

Signaling functionalities : 
Securitv Related Information : 
35 The MSC/VLRn needs some information for authentication and 

encryption; this information is obtained from MSC/VLRo, 

Cancellation : 

The HLR indicates to VLRo that the MS is now under control 
40 of another VLR. The "old" TMSI is free for allocation. 
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Location Updating in a new VLR; old VLR not reachable 
This variant of the procedure in the previous section arises 
when the VLR receiving the LAI and TMSIo cannot identify the 
VLRo. In that case the relation between TMSIo and IMSI is lost, 
and the identification of the MS in clear is necessary. The MS 
must receive a new TMSI and reinitialize the process. (See Next 
Section) . 



Reallocation of a new TMSI 

This function can be initiated by the network whenever a 
radio connection exists. The procedure can be included in other 
procedures, e.g. through the means of optional parameters. The 
execution of this function is left to the network operator. 

When a new TMSI is allocated, to an MS, the network must 
prevent the old TMSI from being allocated again until the MS has 
acknowledged the allocation of the new TMSI . 

If an IMSI record is deleted in the VLR by 0&:M action, the 
network must prevent any TMSI associated with the deleted IMSI 
record from being allocated again until a new TMSI is 
successfully allocated to that IMSI. 

If an IMSI record is deleted in the HLR by O&M action, it is 
not possible to prevent any TMSI associated with the IMSI record 
from being allocated again. However, if the MS whose IMSI 
record was deleted should attempt to access the network using 
the TMSI after the TMSI has been allocated to a different IMSI, 
then authentication or encryption of the MS whose IMSI was 
deleted will almost certainly fail, which will cause the TMSI to 
be deleted from the MS, 

Local TMS I unknown 

This procedure happens when a data loss has occurred in a 
VLR and when an MS uses an unknown TMSI, e.g. for a 
communication request or for a location updating request in a 
location area managed by the same VLR. 

Location updating in a new VLR in case of a loss of 
information . 

This variant of the procedure arises when the VLR in charge 
of the MS has suffered a loss of data. In that case the 
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relation between TMSIo and IMST is lost, and the identification 
of the MS in clear is necessary. 

nng^uccessf ul TMSI allocation 

If the MS does not acknowledge the allocation of a new TMSI, 
the network shall maintain the association between the old TMSI 
and the IMSI and between the new TMSJ and the IMSI . 

For an MS-originated transaction, the network shall allow 
the MS to identify itself by either the old TMSI or the new 
TMSI. This will allow the network to determine the TMSI stored 
in the MS; the association between the other TMSI and the IMSI 
shall then be deleted, to allow the unused TMST to be allocated 
to another MS. 

For a network-originated transaction, the network shall 
15 identify the MS by its IMSI. When radio contact has been 

established, the network shall instruct the MS to delete any 
stored TMSI. When the MS has acknowledged this instruction, the 
network shall delete the association between the IMSI of the MS 
and any TMSI; this will allow the released TMSIs to be allocated 

20 to another MS. 

In either of the cases above, the network may initiate the 
normal TMSI reallocation procedure. 

Repeated failure of TMSI reallocation {passing a limit set 
by the operator) may be reported for O&M action. 

2 5 

User identity authentication 

Authentication is performed after the user identity 
(TMSI /IMSI) is known by the network and before the channel is 
encrypted . 

30 Two network functions are necessary: the authentication 

procedure itself, and the key management inside the fixed sub- 
system. 

The authentication procedure 
35 The authentication procedure consists of the following 

exchange between the fixed sub-system and the MS. 

• The fixed sub- system transmits a non-predictable number RAND 
to the MS. 
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o The MS computes the signature of RAND, say SRES, using the 
algorithm A3, and some secret information: the User 
Authentication Key, denoted Ki in the following. 

o The MS transmits the signature SRES to the fixed sub-system. 
5 o The fixed sub-system tests SRES for validity. 

User authentication key management 

The user authentication key Ki is allocated, together with 
the IMSl, at subscription time. 

Ki is stored on the network side in the Home Public Land 
10 Mobile Network (HPCN) , in an Authentication Center (AuC) . A PCN 
may contain one or more AuC. An AuC can be physically 
integrated with other functions, e.g. in a Home Location 
Register (HLR) . 

15 General authenticatio n procedure 

When needed for an MS, the MSC/VLR requests security related 
information from the HLR/AuC corresponding to the MS. This 
includes an array of pairs of corresponding RAND and SRES. 
These pairs are obtained by applying the algorithm A3 to each 

20 RAND and the key Ki . The pairs are stored in the VLR. 

When an MSC/VLR performs authentication, including the case 
of a location updating within the same VLR area, it chooses a 
RAND value in the array corresponding to the MS. It then tests 
the answer from the MS by comparing it with the corresponding 

25 SRES. 

Authentication at location updat ing in a new VLR, 
using TMSI 

In the case when identification is done using TMSI, pairs 
3 0 for authentication are given by the old VLR. The old VLR shall 
send to the new VLR only those pairs which 
have not been used. 

Authentication at location upda ting in a new VLR, 

35 using IMSI tt,. 

When the IMSI is used for identification, or more generally 

when the old VLR is not reachable, the procedure described in 

the previous section cannot be used. Instead, pairs of 

RAN/SRESA are requested directly from the HPCN. 

40 
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Authentication at location upda ting in a new VL.R, — 
uc^ina IMSI, TMSI unknown in ^old ^ VLR 

The case is an abnormal one, when a data loss has occurred 
in the 'old' VLRo. The procedure is the same as the previous 
5 section, except the acts take place after the VLRn is informed 
by the VLRo that the TMSI is known. 

antbf:^ntication at location updating in a new VL.R, 

uc;in q IMSI, old VLR not re achable 
-Lo The case occurs when an old VLR. cannot be reached by the new 

VLR. The procedure for authentication is the same as the prior 
section, except that no message can be conveyed from VLRo, and 
therefore the procedure begins with VLRn. 

15 Authentication with IMSI if auth entication with TMSI 

fails 

If authentication of an MS which identifies itself with a 
TMSI is unsuccessful, the network requests the IMSI from the MS, 
20 and repeats the authentication using the IMSI. Optionally, if 
authentication using the TMSI fails, the network may reject the 
access request or location registration request which triggered 
the authentication. 

25 Re-use of security related informatio n in failure 

situations 

Security related information consisting of sets of RAND, 
SRES and Kc is stored in the VLR, and may be stored in the HLR. 

3 0 When a VLR has used a set of security related information to 

authenticate an MS, it shall delete the set of security related 
information or mark it as used. When a VLR needs to use 
security related information, it shall use a set which is not 
marked as used in preference to a set which is marked as used; 

35 if there are no sets which are not marked as used, then the VLR 
may use a set which is marked as used. It is an operator option 
to define how many times a set of security related information 
may be re-used in the VLR; when a set of security related 
information has been re-used as many times as is permitted by 

40 the operator, it shall be deleted. 
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If a VLR successfully requests security related information 
from the HLR or previous VLR, it shall discard any security 
related information which is marked as used. 

If a VTjR receives from another VLR a request for security 
5 related information, it shall send only the sets which are not 
marked as used. 

If an HLR receives a request for security related 
information, it shall send any sets which are not marked as 
used; those sets shall then be deleted or marked as used. If 
10 there are no sets which are not marked as used, the HLR may as 

an operator option send sets which are marked as used. It is an 
operator option to define how many times a set of security 
related information may be re -sent by the HLR; when a set of 
security related information has been sent as many times as is 
15 permitted by the operator, it shall be deleted. 

Confidentiality Of Signaling Information 
Elements. Connectionless Data And User 
Information Elements On Physical Connections 

20 . . 

Some signaling information elements are considered sensitive 

and must be protected. 

To ensure the identity confidentiality, the TMSI must be 

transferred in a protected mode at allocation time and at other 

25 times when the signaling procedures permit it. 

The confidentiality of user information on physical 

connections concerns the information transmitted on a traffic 

channel on the MS-BS interface (e.g. for speech) . It is not an 

end-to-end confidentiality service. 

30 These four needs for a protected mode of transmission are 

fulfilled with the same mechanism where the confidentiality 

function is an OSI layer 1 function. The scheme described below 

assumes that the main part of the signaling information element 

is transmitted as control traffic. 

3 5 Four points have to be specified 

o The encryption method, 
o The key setting, 

o The starting of the encryption and decryption processes 
and 

4 0 o The synchronization. 
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The encrypt j-O" method 
The layer 1 data flow (transmitted as control traffic) is 
encrypted by a bit per bit or stream cipher, i.e. the data flow 
on the radio path is obtained by the EXCLUSIVE OR' ing (XORing) 
of the user data flow and an encryption bit stream, generated by 
the an algorithm such as A5 using a key determined as specified 
Key Setting section. The key is denoted by Kc , and is called 

"Encryption Key" . 

The decryption is performed by exactly the same method. 
The algorithm A5 is specified in a later section. 



ypy setting 

Mutual key setting is the procedure that allows the MS and 
the network to agree on the key Kc to be used in the encryption 
15 and decryption algorithm A5 . 

A key setting is triggered by the authentication procedure. 
It may be initiated by the network as often as the network 
operator wishes. 

A key setting must occur in control traffic not yet 
20 encrypted and as soon as the identity of the mobile user (i.e. 
TMSI or IMSI) is known by the network. 

The transmission of Kc to the MS is indirect and uses the 
authentication RAND value; Kc is derived from RAND by using the 
algorithm A8 and the User Authentication key Ki / as defined in 
25 cryptographic algorithm section. 

As a consequence, the procedures for the management of Kc 
are the authentication procedures described in the User Identity 
Authentication section. 

The values Kc are computed together with the SRES values. 
30 The security related information consists of RAND, SRES and Kc . 

The key Kc may be stored by the mobile station until it is 
updated at the next authentication. 

F.nriT- yption kev sequence number 
35 The encryption key sequence number is a number which is 

associated with the encryption key Kc and they are stored 
together in the mobile station and in the network. 

However, since it is not directly involved in any security 
mechanism, it is not addressed in this chapter. 
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of the ^T^n-rvption and decryp rion processes 
The MS and the BS must coordinate the instants at which the 
encryption and decryption processes starts. 

The transition from clear text mode to encrypted mode 
proceeds as follows: Decryption starts in the BS which sends to 
the MS a message containing "Start cipher". Both the encryption 
and decryption start on the MS side after this message has been 
correctly received by the MS. Finally, encryption on the BS 
side starts as soon as acknowledge is received from the MS. 

When a channel is allocated for user data transmission, the 
key used is the one set during the preceding control traffic 
session. The encryption and decryption processes start 
immediately . 

Q yTtr-h-roni z at ion 
The encryption stream at one end and the decryption stream 
at the other end must be synchronized, for the encryption bit 
stream and the decryption bit streams to coincide. The 
underlying synchronization scheme is described xn the 
implementation Indication portion of the Specification of the A5 
algorythm . 

Hand- over 

When a hand-over occurs, the necessary information (e.g. key 
Kc initialization data) is transmitted within the system 
infrastructure to enable the communication to proceed from the 
old BS to the new BS, and the synchronization procedure is 
resumed. The key Kc remains unchanged at handover. 



r-ryptoq-raphic a lgorithms 

This chapter specifies the cryptological algorithms which 
are needed to provide the various security features and 
mechanisms defined above. 
35 Three algorithms have been addressed: 

• A3 : authentication algorithm; 

• A5: encryption / decryption algorithm; 

• A8: encryption key generator. 

The algorithm AS must be common to all PCSs and all mobile 
stations (in particular, to allow roaming). However, up to 8 



40 



JSDOCID: <WO 9713353A1_L> 



wo 97/13353 PCT/US96/15190 

213 

different versions of the algorithm A5 (including no encryption) 
may be specified. 

The algorithms A3 and A8 are at each PCS operator 
discretion. Only the formats of their inputs and outputs must 
5 be specified. It is also desirable that the processing times of 
these algorithms remain below a maximum value. 

.qnecif icat ion of A5 

As defined the algorithm A5 realizes the protection of both 
10 user data and signaling information elements at the physical 
layer . 

Synchronization of both the encryption and decryption 
(especially at hand-over) must be guaranteed. 

15 Implementation indic ations 

The algorithm A5 is implemented into both the MS and the BS . 
On the BS side, it is assumed in the following that one 
algorithm A5 is implemented for a traffic channel. 

The encryption takes place just before modulation and after 
20 interleaving; the decryption takes place just after demodulation 
symmetrically. Both encryption and decryption need the 
algorithm A5 . They start at different times. 

Due to the TDMA techniques used in PCS2000, the useful data 
(i.e. the plain text) is organized in blocks of 160 bits. Each 
2 5 block is incorporated into a normal burst and transmitted during 
a time slot . 

For encryption, produces a sequence of 160 encryption/ 
decryption bits (here called BLOCK) which is combined by a bit 
wise module 2 addition to the 160 bits plain text block. The 
30 useful information bits in a block are numbered eO to el 59. 

The first encryption/decryption bit Produced by A5 is added to 
eO, the second to el and so on. As an indication, the resulting 
160 bits block is then applied to the burst builder. 

For each slot, the decryption is performed on the MS side 
35 with the first block (BLOCKl) of 160 bits produced by A5 , and 
the encryption is performed with the second produced block 
(BLOCK2) . As a consequence, on the network side BLOCKl is used 
for encryption and BLOCK2 for decryption. Therefore, the 
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algorithm AS must produce two blocks of 160 bits {i.e. BLOCKl 
and BLOCK2) . 

Synchronization is guaranteed by driving the algorithm A5 by 
an explicit time variable, COUNT, derived from the IDMA frame 
number. Therefore, each 160 bit block produced by A5 only 
depends on the TDMA frame numbering, and of the encryption key 
Kc. 

COUNT is expressed in 22 bits as the direct frame count. It 
is an input parameter of the algorithm A5 . 

Bit 22 is the most significant bit (msb) and bit I the least 
significant bit (Isb) of COUNT. 



External specificati on of A5 
The two input parameters (COUNT and Kc) and the output 
15 parameters {BLOCKl and BL0CK2) of the algorithm A5 shall follow 
the following formats: 

length of Kc 64 bits; 

length of COUNT: 22 bits; 

length of BLOCKl: 16 0 bits; 
20 length of BLOCK2 : 160 bits. 

The algorithm A5 shall produce BLOCKl and BLOCK2 in less 
than a TDMA frame duration 

NOTE: If the actual length of the encryption key is less 
than 64 bits, then it is assumed that the actual encryption key 
25 corresponds to the most significant bits of Kc, and that the 
remaining and less significant bits are set to zero. 

Tn^g>rnal specificat ion of AS 
The internal specification of A5 (i.e. any version of A5) is 
30 not included in this recommendation. 

Negotiation of A5 
This recommendation allows more than one A5 algorithm and an 
unencrypted mode of operation to be used. It provides support 
3 5 for up to seven encryption algorithms to provide the 

functionality of A5 . This is compatible with roaming, it 
enables the use of different algorithms in different regions, 
and it will allow old algorithms to be phased out and new ones 
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to be phased in, in case that such measures should be deemed 
necessary . 

Two versions of A5 have been defined for the short term 
solution: A5/1 and A5/2 . 

When an MS wishes to establish a connection with a PCS 
network, the MS shall indicate to the network which (if any) of 
the version (s) of the A5 algorithm it is prepared to use. The 
network shall compare its encryption capabilities and 
preferences, and any special requirements of the subscription of 
the MS, with those indicated by the MS and shall act according 
to the following rules: 0 If the MS and the network have no 
versions of the A5 algorithm in common and the network is not 
prepared to use an unencrypted connection, then the connection 

shall be released. 

• If the MS and the network have at least one version of 
the A5 algorithm in common, then the network shall select one 
of the mutually acceptable versions of the A5 algorithm for use 
on that connection. 

• If the MS and the network have no versions of the A5 
algorithm in common and the network is willing to use an 
unencrypted connection, then an unencrypted connection shall be 
used. 

Specification of A3 

The algorithm A3 may be specified by the PCS providers. 

The purpose of the algorithm A3 is to provide an 
authentication of a mobile user's identity. 

The algorithm A3 must compute an expected response SRES from 
a random challenge RAND sent by the network. For this 
computation, A3 makes use of the secret authentication key Ki . 



Tmpl foment at ion and operar ional requirements 
On the MS side, the algorithm A3 is contained in a User 
Identity Module, as specified in the Security Features section 
3 5 of the Privacy & Authentication portion. 

On the network side, it shall be implemented in HLR/AuC . 
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R-xrt-ernal specification of A3 
The two input parameters (RAND and Ki) and the output 
parameter (SRES) of the algorithm A3 shall follow the following 
formats ; 

5 length of Ki : 128 bits; 

length of RAND: 128 bits; 

length of SRES: 32 bits. 

The run-time of the algorithm A3 shall be less than 500 ms . 

10 Specification of AB 

The algorithm A8 may be specified by the PCS providers, as 

the algorithm A3 . 

As defined the algorithm A8 must compute the encryption key 
Kc from the random challenge RAND sent during the authentication 
15 procedure, using the authentication key Ki . 

Tmplempnt-ation and ope rational requirements 
On the MS side, the algorithm AB is contained in the UIM, as 
specified in the Security Features section of the Privacy & 
20 Authentication portion. 

On the network side, the algorithm A8 shall be co- located 

with the algorithm A3 . 

An algorithm A38 may perform the combined functions of A3 

and AB . 

25 

F.-xternal specific ation of A8 
The two input parameters (RAND and Ki) and the output 
parameter (Kc) of the algorithm AB shall follow the following 
formats : 

30 length of Ki : 128 bits; 

length of RAND: 128 bits; 

length of Kc: 64 bits. 

Since the max length of the actual encryption key is fixed, 
the algorithm AB shall produce this actual encryption key and 
35 extend it (if necessary) into a 64 bit word where the non- 
significant bits are forced to zero. It is assumed that any 
non- significant bits are the least significant bits and that the 
actual encryption key is contained in the most significant bits. 
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T.q-54 Based Authentication, Encrypt ion of Signaling 
Tnfn-rmat ion/User Data an d Voice Privacy 

Messages received during the authentication procedures that 
5 are unrelated to the authentication process shall also be 
processed . 

Ani-hf^ntication 

The term "authentication" refers to the process during which 
10 information is exchanged between a mobile station and the base 

station for the purposes of enabling the base station to confirm 
the identity of the mobile station. In short, a successful 
outcome of the authentication process occurs only when it can be 
demonstrated that the mobile station and base station possess 
15 identical sets of Shared Secret Data (SSD) . 

Shared Secret Data (SSD) 
SSD is a 128 -bit pattern stored in the mobile station (in 
semi -permanent memory) and readily available to the base 
20 station. SSD is partitioned into two distinct subsets. Each 
subset is used to support a different process. Specifically, 

SSD-A which is 64 bits is used to support the authentication 
procedures; and SSD-B also 64d bits is issued to support voice 
privacy and message confidentiality. 

25 

Random Challenge Memory (RAND) 
Random Challenge Memory (RAND) is a 32 bit value that is 
held in the mobile station. It is the concatenation of the last 
RANDl A and RAND1_B values received in Random Challenge A and 

30 Random Challenge B Global Action Messages appended to the 
overhead message train. Both RANDl -A and RANDl. B must be 
received on the same control channel and in the same Overhead 
Message Train in order for a valid RAND to exist. RAND^ is used 
in conjunction with SSD-A and other parameters, as appropriate, 

35 to authenticate mobile station originations, terminations and 
registrations . 

Call History Parameter (COUNTSe o) 
Call History Parameter (COUNTs.p) is a modalo-64 count that 
4 0 is held in the mobile station. COUNTs.p is updated at die mobile 
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upon receipt of a Parameter Update Order on the FVC or the 
Parameter Update Message on the FDTC . 

Authentication of Mobile Station Registrations 
5 When the information element AUTH in the System Parameter 

Overhead Message is set to 1, and the mobile station attempts to 
register, the following authentication-related procedures shall 
be performed : 

In the mobile station, 
-LQ o initialize the authentication algorithm (CAVE) ; 

o execute the CAVE procedure; 

set AUTHR equal to the 18 bits of CAVE algorithm 
output ; 

o send AUTHR together with RANDC (eight most significant 
3^5 bits of RAND) and COUNTs-p to the base station 

(Authentication Word C of RECC Autonomous Registration 
Order Message) . 
At the base station, 

o compare the received values for RANDC, and 
20 ■ optionally COUNT, with the internally stored 

values associated with the received MIN/ESN; 
o compute AUTHR as described above, except use the 

internally stored value of SSD-A; and 
o compare the value for AUTHR computed internally 

25 with the value of AUTHR received from the mobile 

station . 

If any of the comparisons by the base station fail, the base 
station may deem the registration attempt unsuccessful, initiate 
the Unique Challenge-Response procedure, or commence the process 
3 0 of updating the SSD. 

TTnioue Challenge -Response Procedure 
The Unique Challenge -Response Procedure is initiated by the 
base station and can be carried out over any control traffic. 
3 5 More specifically : 

At the base station, 

o a 24 -bit, random pattern referred to as RANDU is 
generated and sent to the mobile station via 
control traffic. 
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• initialize CAVE; 

• execute the CAVE algorithm ; 

• set AUTHU equal to the 18 bits of the CAVE 
algorithm output . 

5 At the mobile station, 

• compute AUTHU as described above using the 
received RANDU and its internally stored values 
for the remaining input parameters; 

• send AUTHU to the base station via control 
10 traffic. 

Upon receipt of the Unique Challenge Order Confirmation from 
the mobile station, the base station compares the received value 
for AUTHU to that generated/stored internally. If the 
comparison fails, the base station may deny further access 
15 attempts by the mobile station, drop the call in progress, or 
initiate the process of updating the SSD . 

Authentication of Mobile Station Originations 
When the mobile station attempts to originate a call, the 
20 following authentication related procedures shall be performed: 
In the mobile station, 

• initialize CAVE; 

• execute the CAVE algorithm; 

• set AUTHR equal to the 18 bits of the CAVE 
25 algorithm output. 

• send AUTHR together with RANDC (eight most 
significant bits of RAND) and COUNTs-p to the base 
station via control traffic; 

At the base station, 
30 • compare the received values for RANDC, and 

optionally COUNT, with the internally stored 
values associated with the received MIN/ESN; 

• compute AUTHR as described above, except use the 
internally stored value of SSDA; and 

3 5 • compare the value for AUTHR computed internally 

with the value of AUTHR received from the mobile 
station. 

If the comparisons at the base station are successful, the 
appropriate channel assignment procedures are commenced. 
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If any of the comparisons by the base station fail, the base 
station may deny service, initiate the Unique Challenge-Response 
procedure , or commence the process of updating the SSD. 

5 Atithentication of Mobile Station Terminations 

When a "Page Match" occurs, the following authentication- 
related procedures shall be performed: 
o In the mobile station, 
o initialize CAVE; 

o execute the CAVE algorithm; 

o set AUTHR equal to the 18 bits of the CAVE 

algorithm output . 
o send AUTHR together with RANDC (eight most 

significant bits of RAND) and COUNT^.p to the base 
station via control traffic; 
o At the base station, 

o compare the received values for RANDC, and 

optionally COUNT, with the internally stored 
values associated with the received MIN/ESN; 
20 o compute AUTHR as described above, except use the 

internally stored value of SSDA; and 
o compare the value for AUTHR computed internally 

with the value of AUTHR received from the mobile 
station. 

25 If the comparisons at the base station are successful, the 

appropriate channel assignment procedures are commenced. 

If any of the comparisons by the base station fail, the base 
station may deny service, initiate the Unique Challenge 
procedure, or commence the process of updating the SSD. 

30 

Updating the Shared Secret Da ta (SSD) 
Updating the SSD involves the application of CAVE, 
initialized with mobile station specific information, random 
data and the mobile station's A-key. The A-key is: 
35 o 64 bits long; 

o assigned to the mobile station; 

o stored in the mobile station's permanent security and 
identification memory; and 
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• is known only to the mobile station and its associated 

HLR/AC. 

An A-key must be entered into the mobile station. 
More specifically, updating the SSD in the mobile station 
5 proceeds as follows: 

At the base station, 

• send an Update Command, with the RANDSSD field set 
to the same 9 bit random number used in the HLR/AC 
computations, to the mobile station in control 

10 traffic. 

In the mobile station, 

• upon receipt of the Update Command, initialize 

CAVE; 

• execute the CAVE algorithm; 

15 • set SSD-A_NEW equal to the 64 most significant 

bits of the CAVE algorithm output, and SSD-B__NEW 
to the 64 least significant bits of the CAVE 
algorithm output; 

• select a 32-bit random number, RANDBS, and send it 
20 to the base station in a Base Station Challenge 

Command in control traffic. 

• re- initialize CAVE; 

• execute the CAVE algorithm; and 

• set AUTHBS equal to the 18 bits of the CAVE 
25 algorithm output. 

In the base station, 

• upon receipt of the Base Station Challenge 
Command, initialize CAVE, where RANDBS is set to 
the value received in the Base Station Challenge 

3 0 Command ; 

• execute the CAVE algorithm; 

• set AUTHBS equal to the 18 bits of the CAVE algorithm 

output ; and 

• acknowledge receipt of the Base Station Challenge 
3 5 Command by including AUTHBS in the Base Station 

Challenge Command Confirmation message, which is 
sent in control traffic. 
In the mobile station, 
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o upon receipt of the Base Station Challenge Command 
Confirmation, compare the AUTHBS received to that 
generated internally 

o acknowledge receipt of the Update Command as 
follows : 

o if the comparison at the mobile station is 

successful, set SSD-A and SSD-B to SSD-A_NEW 
and SSD-B_NEW, respectively, and: 
o send an order confirmation message to 
the base station in control traffic, 
o if the comparison at the mobile station fails, 
discard SSD-A_NEW and SSD-B-NEW, and: 
o send an order confirmation message to the 
base station in control traffic, 
in the base station, if the SSD Update Confirmation received 
from the mobile station indicates a success, set SSD-A and SSD-B 
to the values received from the HLR/AC (see EIA/TIA IS-41) . 

rj^\rp. Algorithm 

The availability of CAVE algorithm information is governed 
under the U.S. International Traffic and Arms Regulation (ITAR) 
and the Export Administration Regulations. 

.q-ignalina Messag e Encryption 

In an effort to enhance the authentication process, and to 
protect sensitive subscriber information (e.g., PINs) , 
provisions have been made to allow for the encryption of a 
select subset of signaling messages. Note that some fields of 
the messages subject to encryption are always transmitted as 
plain text. Order /Message Type fields, for example, are never 
encrypted . 

Voice Privacy 

The term "voice privacy" refers to the process by which user 
voice transmitted over a digital traffic channel is afforded a 
modest degree of cryptographic protection against eavesdropping 
in the mobile station - base station segment of the connection. 

Note that regardless of when voice privacy is activated, the 
data used to initialize the algorithm is computed based on 
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parameters in effect at the time the AUTHR appended to the 
origination/page response message was computed. 

Voice Privacy Control 
Requests to activate/deactivate the voice privacy feature 
may be made during the call setup process or while the mobile 
station is in the conversation state. In either case, however, 
the decision to honor the request lies with the base station. 
Furthermore, the mobile station must not act under the 
assumption that the request has been granted until it receives 
positive verification from the base station. 



Voice Privacy Control Purina Call Establishment 
Mobile Station Originations 
-L5 To request activation of voice privacy on mobile station 

originations, the MS sends the BS a Set Cipher Command with 
cipher set to 1. 

Mobile Station Terminations 
20 To request activation of voice privacy on mobile station 

terminations, the BS sends the MS a Set Cipher Command with 
cipher set to 1 . 

Voice Privacy Control After Ini tial Channel As 
25 To request a change in the privacy mode, the MS sends the BS 

a Set Cipher Command with cipher set to the appropriate state. 

Cipher Placement 
Enciphering shall take place after error correction coding 
30 and before interleaving. In particular, note that user voice is 
enciphered while still represented as bits rather than 
quaternary symbols. Similarly, deciphering occurs after de 
interleaving . 

3 5 Voice Privacy Algorithm 

The availability of this information is governed under the 
U.S. International Traffic and Arms Regulation (ITAR) and the 
Export Administration Regulations. 
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Air Interface Description 

Transmitter Power Output C haracteristics 
Mobile Station (MS) 

Although the FCC permits up to 2 Watts Effective Isotropic 
Radiated Power (EIRP) for the MS, the peak EIRP of the MS is a 
nominal 1 Watt. The average power delivered to the antenna is 
less than 1 0 milliwatts for each 8 kbps time slot, permitting 
long durations between MS battery recharges. The constant 
envelope characteristic of the modulation technique permits use 
of an efficient non- linear output amplifier which further 
reduces battery drain. 

Base Station (BS) 

The FCC rules permit up to 164 0 Watts peak EIRP per RF 
channel for PCS Base Stations. Since the BS peak power output 
to its antenna is 2 Watts, the maximum permissible BS antenna 
gain (ignoring feed losses) is therefore limited by the FCC rule 
to 29.15 dB. 

Modulation Charact eristics 

Functional Description of Spread Spectrum Modulator 
To produce the direct sequence spread spectrum (DSSS) 
characteristic of the system RF signal, a form of continuous 
phase shift quadrature modulation (CPM) called Spectrally 
Efficient Quadrature Amplitude Modulation (SEQAM) is used. This 
provides a constant amplitude for the envelope of the modulated 
carrier. The constant envelope modulation permits efficient 
non- linear RF power amplification (especially desirable for long 
hand set battery life) , without spectral regrowth of modulation 
sidelobes. DSSS conveyance of information is accomplished by 
using multiple DSSS PN chip sequences to encode the baseband 
data. The PN sequence modulates the carrier to a 5 MHZ 
bandwidth. By shaping the PN chip waveforms before modulation, 
all modulation sidelobes at frequencies more than one -half the 
chip rate away from the center frequency of the DSSS RF signal 
are greatly attenuated 

The functional description covers the basic architecture of 
the modulation utilized by the system. The waveform generated 
depends on the relationship between the I and Q states over 
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several chip intervals and the successive values of I and Q. 
These successive values depend on the spreading codes being sent 
over I and Q . 

The transmitter output power spectrum of the modulation 
5 after hard limiting or saturation of the power amplifier shall 
be measured using a 30 kHz resolution bandwidth with averaging 
performed over 50% to 90% of each TD^4A transmit burst and over 
500 or more bursts. 

The baseband waveform of the I or Q baseband signal before 
10 application to the I/Q modulator shall be defined with each I 
and Q chip symbol rate at 2 . 5 MHZ. The I and Q chip symbol 
streams together shall form the 5 MCPS complex signal. 

System Time and Frequency Synchronizatio n Characteristics 
15 Base Stat ion- to-Network and Base Stat ion-to Base 

Station Synchronization 

The Base Station provides the basic TDIVIA loop timing 
structure for its cell or sector. To maximize PCS system 
throughput capacity, the TDMA frame times for all Base Stations 

20 within the same geographical area should be synchronized. For 
example, one method of obtaining the required timing is to 
utilize a GPS receiver at the Base Station Controller (and 
optionally at the BS) to generate the primary reference timing 
marker for the TDIVIA frame timing. This marker is captured at 

25 the Base Station Controller every second and transmitted down 
the backhaul lines to the attached Base Stations. 

This synchronization of Base Stations within a given 
multicell PCS deployment allows a Base Station Controller to 
temporarily turn off any TDIVIA time slot of a given cell which 

30 may be interfering with a neighboring cell. It also facilitates 
Time Slot Interchange (TSI); i.e., switching a MS to a different 
time slot if a current time slot is being interfered with by an 
adjacent cell using the same time slot. 

3 5 Base Stat ion- to-Network Syn chronization 

The primary data timing standard in a digital network 
backhaul system, such as Tl or ISDN BRI or PRI , is the PSTN 
timing standard. To prevent data precession into overrun or 
under-run, the Base Station Controller and its Base Stations are 
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synchronized to the PSTN tithing standard. The actual data 
movement clock, generated by the PSTN and rendered to an 8 kHz 
timing marker, is used by the system to get the data rate 
throughput . 

5 Sufficient variable length guard times have been provided in 

the frames and time slots to permit synchronization between 
diverse timing mechanisms, e.g. if GPS timing is used at the BS 
or BSC, and PSTN timing is used in the network. 

LO Mobile Station-tO'Base Station Sync hronization 

The Mobile Station can synchronize to a new Base Station 
within one channel (time slot) and is capable of synchronizing 
with multiple Base Stations when those Base Stations are 
synchronized to a common digital network. The system allows 

15 noncoherent detection to be used by the BS and MS receivers, and 
they do not have to be phase -locked. However, the transmit and 
receive local oscillator frequencies of the BS and MS are 
automatically controlled to prevent data precession between the 
BS and MS . 

20 

Power Control Method 

The technology is based on a TDMA structure. Therefore, it 
does not require the strict control of transmitter RF power 
output necessary to resolve the "Near- Far" problem experienced 
25 by most CDMA systems. The Base Station transmits a Power 

Control Command (PCC) at the beginning of its transmit period. 
The PCC provides a power control signal to adjust the MS power 
output level to a value just large enough to provide the 
required signal-to-noise plus interference ratio at the BS, as 
3 0 determined by the quality of the received PCP signal from the 
MS . This is done : 

*to minimize interference to other cells, which may be 
operating on the same or adjacent RF channels 
*for each time slot independently of other time slots in a 
3 5 frame 

*for each time slot, and, therefore, has a very low latency 

in the power adjustment process 

*to reduce Mobile Station battery consumption 
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Contirol of Transmitter Power Output 
The system utilizes a Power Control Pulse (PCP) . The PCP is 
transmitted by the MS in its assigned TDMA time slot just before 
the BS transmits to that MS in its associated TDD time slot. 
5 This MS PCP provides the BS with a measurement of the MS-BS path 

transmission loss, which serves as the basis for the BS transmit 
power level to that MS, as well as a Power Control Command (PCC) 
transmitted from the BS to the MS. The PCC causes the MS to 
change its output power in nominal steps of 3 dB (over a maximum 
10 33 dB range) , to a value just large enough to provide the 

required signal-to-noise plus interference ratio at the BS, as 
determined by the quality of the PCP received by the BS . This 
power control method works especially well for TDD systems since 
both forward and reverse channels using the same RF carrier 
15 frequency experience identical path losses. BS power is 

controlled on a channel (time slot) by channel {time slot) basis 
for each channel (time slot), independently of other channels 
(time slots) . 

In the TDD/TDMA frame design, the elapsed time for an entire 
20 TDID channel (time slot) shall be less than 500 - - less than 

2.5% of the frame time. Because of this fast response time, the 
Power Control algorithm acts faster than the RF channel changes 
due to small scale multipath fading and shadowing, and helps to 
mitigate any performance degradation caused by these effects. 

25 

Control of Mobile Station Power Output 

To permit RF channel reuse in nearby PCS cells, reduce 
interference with OFS users, and conserve battery power in the 
handheld units. The technology provides adaptive power control 

30 of the Mobile Station transmitters within each PCS cell. In 

some TDMA systems, the latency of the polling loop frame signals 
prevent the use of closed loop power control. However, with the 
TDD/TDMA frame design, the elapsed time for an entire TDD 
channel (time slot) is less than 500 /xs less than 2.5% of the 

3 5 frame time. Because of this fast response time, the Power 

Control algorithm acts faster than the RF channel changes due to 
small scale multipath fading and shadowing, and helps to 
mitigate any performance degradation caused by these effects. 
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System Performance Requirements 
RF Channel Plan 

The system shall utilize the following channelization plan. 
There are several sequential hex numbers, currently omitted, 
5 that are held in reserve for later use. The system cellular 

frequency plans in the licensed frequency blocks will normally 
use channels that are separated by 5 MHZ. However, it is 
possible to use any frequency between 1850 and 1990 MHZ, in 650 
Khz increments, i.e. 1850 MHZ, 1850.625 MHZ, etc. Each 
10 frequency is assigned a unique hex number for system use, the 
frequencies are numbered sequentially. 

Channel (Time Slot) Composition 

Each channel (time slot) shall be composed of six elements 
15 and accommodates the complete transaction between a BS and a MS. 
The Guard Times include a maximum TDID turn around time of 4.4 
microseconds. The following tables show the time durations for 
each element of both the 32 and 25 channel TDMA frames. 
Parentheses indicate the times associated with a 25 channel 
20 deployment configuration. 



Information Element 


Length in Time (microseconds) 


PCP 


12 .8 


Guard Time 1 


35.8 (123.3) 


BS TX 


268.8 


Guard Time 2 


4.4 


MS TX 


268 .8 


Guard Time 3 


34.4 (121.9) 



3 0 Base Station Performance Requirements 
Transmitter 

RF Frequency Aailitv 

The transmitter shall be within +/- 10 PPM of the channel 
frequency, when switched from any one frequency to any other 
35 frequency within the same licensed frequency block, in no more 

than 500 microseconds. 
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RF Frequency Accuracy 

The Base Station's transmit RF frequency shall be capable of 
deriving its frequency reference from the digital network 
frequency reference. Under these conditions the Base Station's 
5 transmit frequency shall track the digital network frequency 

reference up to +/-10 PPM limits from the nominal channel 
frequency outlined in RF frequency agility section (over all 
operating conditions). The Base Station's transmitter frequency 
shall be within +/-1 PPM of the nominal channel frequency listed 
10 in RF frequency agility section (over all operating conditions) 
when the Base Station is not synchronized to the network. The 
Base Station shall use a common frequency reference to generate 
the radio frequencies and the data clock. 

IB Base Station Timing and Synchronization 

Timing Jitter 

The timing Jitter on the first chip in a time slot relative 
to the first chip in every other time slot shall be less than 
+/- 200 nanoseconds. The timing jitter between the first chip 
20 in a time slot and every other chip in that time slot shall be 
less than +/- 20 nanoseconds. 

Base Station to Base Station Intra Con troller 
Synchronization 

25 Base Station transmissions will be synchronized to one 

another such that they transmit time slot 1 from the antenna 
within 3.2 microseconds (maximum) of each other. 

Base Station to Base Station Inter Controller 
3 0 Synchronization 

Base Station transmissions will be synchronized to one 
another such that they transmit time slot 1 from the antenna 
within 3.2 microseconds (maximum) of each other. 

3 5 Power Output 

TDMA Power Waveform vs . Time 

The transmitter shall have a controlled on-off switching 
characteristic to meet the FCC spurious emissions requirements. 
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The transmitter output shall not exceed -108 dbm during any 
receive time slot . 

Peak RF Power Output 
5 The Base Station transmitter shall be capable of 2 Watts 

(+/- 1.5 dB) peak output in the licensed frequency bands. 

PF Power Control 

The technology shall utilize a Power Control Pulse (PCP) , 
10 transmitted- by the MS in its assigned TDMA time slot just before 
the BS transmits to that MS in its' associated TDD time slot. 
The PCP shall be a 64 chip PN sequence. This MS PCP provides 
the BS with a measurement of the MS-BS path transmission loss, 
which serves as the basis for the BS transmit power level to 
15 that MS, as well as a Power Control Command (PCC) transmitted 

from the BS to the MS. The PCC shall cause the MS to change its 
output power to a value just large enough to provide the 
required signal-to-noise plus interference ratio at the BS, as 
determined by the quality of the PCP received by the BS . The 
20 PCC is included as a 3 bit field in the packet header. The peak 
RF power output level shall be capable of power control on a 
time slot by time slot basis over a nominal control range of 33 
dB. Step sizes shall be monatomic with nominal steps of 3 dB . 

2 5 Spurious RF Emissions 

Conducted Emissions 

Conducted emissions shall comply with FCC Part 24.238 - 
Emission Limits for the licensed PCS bands. 



3 0 Radiated Emissions 

Radiated emissions shall comply with FCC Part 15 rules for 
incidental and intentional radiators. The radiated emissions 
shall also comply with ANSI C95. 1-1991. 

3 5 Total 5^purious Emissions 

All spurious emissions and out of band emissions shall 
comply with FCC Part 24.238 Emission Limits for the licensed PCS 
bands. All spurious emissions include: modulation spectral 
sidelobes, transmitter harmonics, transmitter on-off switching 
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transient emissions, power control transients, or multiple co- 
sited transmitter intermodulat ion products. 

nirf:^ct Sequence Spread Spectrum C haracteristics 
n.q.q.q chi p Rate 

The DSSS chip rate shall be 5 megachips per second (Mcps) . 
Ag gregate TDMA Bit Rate 

The aggregate TDMA bit rate shall be 781.25 kbps . Aggregate 
TDMA bit rate is defined to be the total number of bit periods 
that occur within one second and include PCP, guard times, idle 
slots, control bits and user bits. 

PN Code Characteristics 
15 The PN codes employed to produce the direct sequence spread 

spectrum characteristics of the RF signal shall provide an 
inherent frequency diversity for the RF signal which shall 
mitigate the detrimental effects of mult ipath- induced Rayleigh 
fading and delay spread which occur in typical PCS mobile user 
20 environments. A frequency diversity gain proportional to the 

ratio of the DSSS spread bandwidth to the coherence bandwidth of 
the fading channel shall be provided. Spread spectrum 
correlation detection of the DSSS signal shall reject multipath 
components delayed by more than one PN chip time, and thereby 
25 mitigate the effects of intersymbol interference caused by 

multipath delay spread without the need for adaptive equalizers. 

The low power density of the DSSS signal shall also mitigate 
the potential interference with nearby OFS users. 

The DSSS PN codes assigned to cells in a multicell PCS 
3 0 deployment shall be quasiorthogonal to the PN codes employed by 
nearby cells reusing the same RF frequency. By utilizing the 
Code Division Multiple Access (CDMA) characteristics of quasi - 
orthogonal PN code sets, a Frequency Reuse factor of N = 3 shall 
be provided by utilizing the processing gain of the DSSS, in 
35 conjunction with the propagation loss associated with the two 
cell physical separation of any two cells using the same 
frequency, to reject the co-channel interference caused by 
frequency reuse. 
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CDMA PN Coded Packets 

Each packet shall consist of 1280. PN chips at 5 Mcps , 
transporting 200 bits. Code selection is application specific, 
with a selection field of 2 200 sequences designed for code 
5 orthogonality of 24 dB over the length of the sequence per 

packet. Sequences vary for each remote unit, from BS to BS and 
packet to packet . The packet shall contain a burst preamble 
with a 64 chip PN sequence. 

10 Receiver 

Frequency Aailitv 

The receiver shall be capable of being switched in frequency 
from any one frequency to any other frequency within the same 
licensed frequency block, and become fully operational within 
15 500 microseconds after being switched. 

Frequency St ability/ Synchronization 

The same master clock that is used for transmit shall be 
used for receive. 

20 

Sensitivity 

The minimum receive sensitivity shall be -102 dBm for a 10-3 

BER. 

2 5 Co- Channel Performance 

Signals 

The minimum co-channel interference (C/1) performance shall 
be 6 dB . An "On Channel" PCS 2000 RF signal shall be adjusted 
to 20 dB above the measured receive sensitivity for a 10"^ BER. 
30 A second "On Channel" signal using another DSSS code set shall 
be adjusted to within -6 dB of the first RF signal. The BER 
shall not exceed 10'^ BER. 

Signals 

35 The minimum co-channel interference (C/1) performance shall 

be 4 dB for CW interferers. An "On Channel" RF signal shall be 
adjusted to 20 dB above the measured received sensitivity for a 
10'^ BER. A second "On Channel" CW signal shall be adjusted to 
within -4 dB of the signal. The BER shall not exceed 10'^ BER. 
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Multipath Performance 

The receiver shall be able to maintain a BER of 10'- minimum 
when receiving a signal with the multipath conditions as shown 
in the following table: 



Tap 


Rel Delay (nSec) 


Avg Power (dB) 


1 


0 


0 


2 


0-6000 


-3 . 0 



10 



Minimum Receiver Performance in Multipath 



15 



Test Conditions: No fading, static multipath test 

0-6 
00 phase 

Radio test performed at Eb/No=20dB 



Ari-iac:gnt Channel P erformance 

The minimum adjacent channel receiver performance shall be 
20 determined by the ratio in dB of two signals; where one signal 
(center frequency) is on the desired channel, the other signal 
(center frequency) is on an adjacent channel, and the desired 
signal is communicating with the receiver at a BER of 10"^ 
Minimum performance specifications are listed in the following 
25 chart: 



30 



35 



Adj Chan 
Spacing 


Modulation 
Type 


On Chan Signal 
Power 


Min Spec 


5 MHZ 


PCS2000 


+ 2 dB above sens , 


25 dB 


2.5 MHZ 


PCS2000 


+ 2 dB above sens . 


7 dB 


5 MHZ 


PCS2000 


+2 0 dB above sens. 


30 dB 


2.5 MHZ 


PCS2000 


+20 dB above sens. 


9 dB 


5 MHZ 


CW 


+2 dB above sens . 


70 dB 


2.5 MHZ 


CW 


+2 dB above sens. 


4 5 dB 


5 MHZ 


CW 


+2 0 dB above sens. 


70 dB 


2.5 MHZ 


CW 


+20 dB above sens. 


50 dB 
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Minimum Adjacent Channel Performance 



Tntermodulation Pe rformance 

The minimum receiver intermodulat ion performance shall be 
5 determined by using three signal sources. One signal source 
shall be an "On Channel PCS2000" signal source, and the other 
two signal sources shall be CW sources located at 5 MHZ and 10 
MHZ above the desired "On Channel" frequency. The test shall be 
repeated with the two CW signal sources located at 5 MHZ and 10 
10 MHZ below the desired "On Channel" receive frequency. The "On 
Channel" signal shall be adjusted to 2 dB above the receiver 
sensitivity of the unit under test. Both CW signals shall be 
adjusted together at the same power level until the receiver BER 
is 10-^ The difference between the "On Channel" signal and the 
15 CW signals shall be 60 dB minimum. 

Spurious RF Emissions 

RF emissions from the Base Station receiver shall meet the 
FCC Part 15 incidental radiator rules. 



20 



Rf>r'p-ived Si anal Strength Indica tor (RSSI 
Performance 

The maximum response time for the RSSI measurement shall be 
5 microseconds. The RSSI shall be monotonic in the measurement 
25 of received signal strength from the receiver sensitivity limit 
to at least a - 60 dBm input signal level. The RSSI resolution 
shall be less than or equal to 1.5 dB . 

Typir-^l Antenr.^ Perform ance Specifications (For reference only) 
Base Stations may be configured with either omnidirectional 
or high gain directional antennas (or a combination) depending 
on the specific RF coverage needs for each base site. In 
addition, to permit a Base Station to cover a large sparsely 
populated area, steerable phased array antennas may be used. 



30 



35 



Dmn-idirecf -i onal A ntennas 
Gain 

Omnidirectional antennas shall have a nominal gain of 5 to 
10 dBi. 
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Vf^rtiical Beamwidth 
Omnidirectional antennas shall have a nominal vertical 
beamwidth of 8 to 35 degrees. 

Po1 arization 

Omnidirectional antennas shall be vertically polarized. 

Directional Antennas 
Gain 

Directional antennas shall have a nominal gain of 10 to 17 

dBi . 



Vertical Beamwidth 
Directional antennas shall have a nominal vertical 
15 beamwidth of 7 to 35 degrees. 

Ay.imuthal Beamwidth 

Directional antennas shall have a nominal azimuthal 

beamwidth of 15 to 120 degrees with a minimum front -to-back 
2 0 ratio of 2 0 dB , 

Phased Arrav (Steered) Antennas 

Phased array antennas may be either vertically or circularly 
polarized . 



Gain 

Phased array antennas shall have a maximum gain of 2 9 dBi 

Vertical Beamwidth 
Phased array antennas shall have a nominal vertical 
beamwidth of 8 degrees. 



Ay.imuthal Beamwidth 
Phased array antennas shall have a nominal azimuthal 
35 beamwidth of 8 degrees with a minimum front - to-back ratio of 20 
dB. 
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niversitv fn-r Mitigation of Multipath Effects 
.q patial Div ersity 

The Base Station shall use spatial antenna diversity with 2, 
3, or 4 antennas -depending on the severity of the multipath 
5 conditions of each base site. 

Antenna gp^l factio n Algorithm 

Both RSSI and correlation scores shall be employed by the BS 
to determine the signal quality received for each antenna from 
10 each PCP message received at the BS . The results of these 
measurements shall be used to select the best antenna for 
transmission within the same TD^4A time slot (channel) . 

Operating Cond itions 
15 Temperature R anges 

Base Stations shall be categorized by temperature ranges. 

Minimum performance requirements shall be met over the 

temperature range specified for a class of Base Station. 

Class Of Base st^fion Temperature Ranges 
20 Class I -10 C to +50 C 

Class II -30 C to +60 C 

Class III -40 C to +70 C 

Mobile Station Perform ance Reguirements 
25 Transmitter 

RF Frecmencv Agility 

The transmitter shall be switchable to within +/- 10 PPM of 
the channel frequency, when switched from any one frequency to 
any other frequency within the same licensed frequency block, in 
30 no more than 500 microseconds. 

Peak Powf^r Output (EIRP) 

The Mobile Station transmitter shall have a maximum peak 
power output of 1 Watt (+/- 1.5 dB) EIRP in the licensed PCS 
3 5 bands . 

TDMA Power Waveform vs . Time 

The transmitter shall have a controlled on-off switching 
characteristic to meet the spurious requirements of section 
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3.3.1.5. The transmitter output shall not exceed -106 dBm during 
any mobile station receive time slot. 

Mobile Station Average Power Output 
5 The mobile station average power output shall be determined 

by the number of channels (time slots) aggregated to deliver the 
desired data rate. For example, each time slot (channel) 
delivers an 8 kbps data rate and transmits 9 . 4 mW (maximum). 
Since a 32 kbps user consumes 4 time slots, it therefore 
10 transmits 4 times the average power output of an 8 kbps user. 

Power control will further reduce the average power output as 
directed by the Base Station. 

Mobile Station Transmit Power Con trol bv Base 

15 Station 

Transmit Power Control shall be directed by the Base Station 
in 3 dB steps over a total range of 33 dB nominal. The 3 dB 
steps shall be accurate to within ±1 dB . 

Time slot (channel) delivers an 8 kbps data rate and 
20 transmits 9 . 4 mW (maximum). Since a 32 kbps user consumes 4 
time slots, it therefore transmits 4 times the average power 
output of an 8 kbps user. Power control will further reduce the 
average power output as directed by the Base Station. 

2 5 Mobile Station Transmit Power Co ntrol bv Base 

Station 

Transmit Power Control shall be directed by the Base Station 
in 3 dB steps over a to range of 3 3 dB nominal. The 3 dB steps 
shall be accurate to within ±1 dB . 



30 



35 



Spurious RF Emissions 
Conducted Emissions 

Conducted emissions shall comply with FCC Part 24.238, 
"Emission Limits for the licensed PCS bands" . 

Radiated Emissions 

Radiated emissions shall comply with FCC Part 15 rules for 
incidental and intentions radiators. The radiated emissions 
shall also comply with ANSI C95. 1-1991- 
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Total Spurious Emissions 

All spurious emissions and out of band emissions shall 
comply with FCC Part 24.238 "Emission Limits for the licensed 
PCS bands" . 

All spurious emissions include: modulation spectral 
sidelobes, transmitter harmonics, transmitter on-off switching 
transient emissions, power control transients, or multiple sited 
transmitter intermodulation . 

n-irect S «=> quence .qpread S nectrum Characteristics 
n.q.q.c; rhip Rate 

The DSSS chip rate shall be 5 Megachips per second (Mcps) . 
Acrareaate TTMA Bit Rate 

The aggregate TDMA bit rate shall be 781.25 kbps . Aggregate 
TDMA bit rate is defined to be the total number of bit periods 
that occur within one second and include PCP guard times, idle 
slots, control bits and user bits. 

PN Code Characteristics 

The PN codes employed to produce the direct sequence spread 
spectrum characteristics of the RF signal shall provide an 
inherent frequency diversity for the RF signal which shall 
mitigate the detrimental effects of multipath- induced Rayleigh 
fading and delay spread which occur in typical PCS mobile user 
environments. A frequency diversity gain proportional to the 
ratio of the DSSS spread bandwidth to the coherence bandwidth of 
the fading channel shall be provided. Spread spectrum 
correlation detection of the DSSS signal shall reject multipath 
components delayed by more than one PN chip time, and thereby 
mitigate the effects of intersymbol interference caused by 
multipath delay spread without the need for adaptive equalizers. 

The low power density of the DSSS signal shall also mitigate 
the potential interference with nearby OFS users. 

The DSSS PN codes assigned to cells in a multicell PCS 
deployment shall be quasiorthogonal to the PN codes employed by 
nearby cells reusing the same RF frequency. By utilizing the 
Code Division Multiple Access (CDMA) characteristics of quasi - 
orthogonal PN code sets, a Frequency Reuse factor of N = 3 shall 
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be provided by utilizing the processing gain of the DSSS, in 
conjunction with the propagation loss associated with the two 
cell physical separation of any two cells using the same 
frequency, to reject the co-channel interference. caused by 
5 frequency reuse. 

CDMA PN Coded Packets 

Each packet shall consist of 1280 PN chips at 5 Mcps, 
transporting 200 bits. Code selection is application specific, 
10 with a selection field of 2 200 sequences designed for code 
orthogonality of 24 dB over the length of the sequence per 
packet. Sequences vary for each remote unit, from BS to BS and 
packet to packet . The packet shall contain a burst preamble 
with a 64 chip PN sequence. 

15 

Mobile Station Receiver 
Frequency Agility 

The transmitter shall be within +/- 1 0 PPM of the channel 
frequency, when switched from any one frequency to any other 
20 frequency within the same licensed frequency block, in no more 
than 500 microseconds. 

Frequency St ability/ Synchronization 

The same master clock that is used for transmit shall be 
25 used for receive. 

Sensitivity 

The minimum receive sensitivity shall be -100 dBm for a 10"^ 
BER. The receiver sensitivity is measured in AWGN. 

30 

Co - Channe 1 Per f ormance 
Signals 

The minimum co-channel interference (C/l) performance shall 
be 6 dB. An "On Channel" PCS 2000 RF signal shall be adjusted 
35 to 20 dB above the measured receive sensitivity for a 10"^ BER. 

A second "On Channel" signal using another DSSS code set shall 
be adjusted to within -6 dB of the first RF signal. The BER 
shall not exceed 10'^. 
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CW Signals 

The minimum co-channel interference (C/l) performance shall 
be 4 dB for CW interferers. An "On Channel" RF signal shall be 
adjusted to 20 dB above the measured receive sensitivity for a 
10'^ BER. A second "On Channel" CW signal shall be adjusted to 
within -6 dB of the first RF signal. The BER shall not exceed 
10-^ 

Multioath Performance 

The receiver shall be able to maintain a maximum BER of 10'^ 
when receiving a signal with the multipath conditions as shown 
in the following table: 



15 



20 



25 



30 



35 



Tap 


Rel Delay (nSec) 


Avg Power (dB) 


1 


0 


0 


2 


0-6000 


-3.0 



Minimum Receiver Performance in Multipath 
Adjacent Channel Performance 

The minimum adjacent channel receiver performance shall be 
determined by the ratio in dB of two signals; where one signal 
(center frequency) is on the desired channel, the other signal 
(center frequency) is on an adjacent channel, and the desired 
signal is communicating with the receiver at a BER of 10*^. 
Other test conditions are listed on the following chart: 



Adj Chan Spacing 


Modulation 
Type 


On Chan Signal Power 


Min Spec 


5 MHZ 


PCS2000 


-1-2 dB above sens. 


50 dB 


2.5 MHZ 


PCS2000 


+2 dB above sens . 


7 dB 


5 MHZ 


PCS2000 


-1-20 dB above sens. 


4 5 dB 


2.5 MHZ 


PCS2000 


+20 dB above sens. 


7 dB 


5 MHZ 


CW 


+2 dB above sens . 


50 dB 


2.5 MHZ 


CW 


+2 dB above sens. 


7 dB 


5 MHZ 


CW 


+2 0 dB above sens . 


55 dB 


2.5 MHZ 


CW 


+20 dB above sens. 


35 dB 



Adj acent Channel Performance 
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Intermodulat ion Performance 

The miniTnuTTi receiver intermodulat ion performance shall be 
determined by using three signal sources. One signal source 
shall be an "On Channel PCS2000" signal source, and the other 
5 two signal sources shall be CW sources located at 5 MHZ and 10 

MHZ above the desired "On Channel" frequency. The test shall be 
repeated with the two CW signal sources located at 5 MHZ and 10 
MHZ below the desired "On Channel" receive frequency. The "On 
Channel" signal shall be adjusted to 2 dB above the receiver 
10 sensitivity of the unit under test. {Receiver sensitivity is 
defined in section 3.2.2.3) Both CW signals shall be adjusted 
together at the same power level until the receiver BER is 10'^. 
The difference between the "On Channel" signal and the CW 
signals shall be 55 dB minimum. 

15 

RSSI Performance (Received Signal Strength Indicator) 
The maximum response time for the RSSI measurement shall be 
300 microseconds. The RSSI shall be monotonic in the 
measurement of received signal strength from the receiver 
20 sensitivity limit to at least a -60 dBm input signal level. The 

RSSI resolution shall be less than or equal to 1.5 dB . 

Spurious RIF Emissions 

RF emissions from the Mobile Station Receiver shall meet the 
25 FCC Part 15 Incidental Radiator rules. 



Typical Handset Antenna Performance Specif ications (For Ref . 
Only) 

Handset Antenna 
30 Gain 

The handset antenna shall have a nominal gain of 2 dBi . 

Vertical Beamwidth 

The handset antenna shall have a nominal vertical beamwidth 
3 5 of 70 degrees, perpendicular to the antenna axis. 

Azimuthal Beamwidth 

The handset antenna shall be omnidirectional and 
perpendicular to the antenna axis. 
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Polarization 

The handset antenna shall be polarized along the major axis 
of the handset . 

Typical Mobile Vehicular Antenna (For Reference Only) 
Gain 

The mobile vehicular antenna shall have a nominal gain of 5 

dBi . 

Vertical Beamwidth 

The mobile vehicular antenna shall have a nominal vertical 
beamwidth of 35 degrees. 

Azimuthal Beamwidth 

The mobile vehicular antenna shall be omnidirectional. 
Polarization 

The mobile vehicular antenna shall be vertically polarized . 

Operating Conditions 

Temperature Ranges 

Mobile Stations shall be categorized by temperature ranges . 
All minimum performance requirements shall be met over the 
temperature range specified for a Class of Mobile Station . 

Class Of Mobile Station Temperature Ranges 

Class I -10 C to +50 C- 

Class 11 -30 C to +60 C 

Class III -40 C to +70 C 

Functional Descriptions of Base Station System 
System Controller 

The System Controller is responsible for managing the Radio 
Link, data movement, global bus arbitration and general system 
supervision . Data received by each radio is evaluated by the 
controller and using a DMA, moves voice and/or control traffic 
between the radio and the Line or OTA Processors respectively . 
Antenna diversity is also managed by the System Controller based 
on received signal strength and statistical inf oirmation . Global 
bus arbitration is controlled by the System Controller and includes 
access priority and access restriction. If redundant OTA or Line 
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Processors are used, the System Controller can be used to designate 
the active modules and restrict global bus access to inactive or 
faulty modules. 



5 OTA Processor 

OTA Processor 1606 is responsible for managing the Over-The-Air 
Protocol. An interrupt at the beginning of each slot signals pTA 
Processor 1606 to start processing data from the previous slot. 
Backhaul communication messages called 'Notes' are generated and 
10 received by OTA Processor 1606 using interrupts to signal the 
receiving processor of a pending message. Dual Port Radio and Line 
Processor bufferscan be used to maximize global bus and processing 
efficiency. Global RAM is also available to OTA Processor 1606. 

15 Interface Processor 

Line Interface Processor 1610 is responsible for managing the 

interface between OTA Processor 1606 and the backhaul Line Card. 

Protocols such as ISDN-BRI or the Omnipoint Proprietary Interface 

will be supported by the Line Interface Processor. A standard 
20 "Notes' interface is used between the OTA and Line Processor (s) to 

minimize the impact caused by changing Line Card types, to the rest 

of the system. 

Line Card 

25 Line Cards 1611 connect the Base Station either directly or 

indirectly to the network. Different Line Card types provide the 
specific hardware/software capabilities required to connect the 
Omnipoint Base Station to various interfaces and protocols. Line 
Cards that interface directly to the network have the speech coder 

30 located on the card. These include but are not limited to the 
standard analog 2500, ISDN-BRI and Tl . Line Cards using HDSL, DS 
I interfaces or high speed modems, connect the base station to Base 
Station Controllers or concentrators. These Line Cards typically 
do not have resident speech coders and transfer data/voice in a 

3 5 packed frame format . 

Radio Interface 

The Radio Interface Circuit Card is responsible for managing 
the interface between the Radio' and the rest of the base station. 
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The base stat ion is capable of suppo^rtiing fi'OTn one to fouir i^adios 
which provides antenna diversity and redundant /back up operation. 
The Radio Interface Circuit Card is considered to be a 'Slave" on 
the Global Bus and can not arbitrate for Global Bus Mastership. 
5 The System Controller will designate one radio to provide Master 
Link Timing using the radio's Global Command Register. The Master 
Link Timing Radio will provide the Link Clock and associated timing 
signals necessary to maintain a synchronized radio link. 

10 Data Bus Monitor 

The Data Bus Monitor plugs into an expansion slot in the Base 
Station back plane to provide realtime global bus monitoring 
capability. Using a PC's parallel print port, the operator can 
configure the Data Bus Monitor to collect data on the global bus 

15 or specific memory locations using interrupts or global bus 
addresses as triggers. Bus masters can also write status messages 
to the Data Bus Monit or which can be displayed on a screen or 
written to the disk for post processing. The Data Bus Monitor can 
be used to simulate a peripheral or as a protocol analyzer. Memory 

20 up and downloads are supported for both global and local memories. 

Global System Bus 

The Global System Bus connects the Radios, System Controller, 

OTA Processor (s) , Line Processor (s) , Line Cards and the Data Bus 
25 Monitor. Each module is memory, mapped into the 16M byte address 

space. Multiple devices can share global resources but function 

independently within their own local memory space. At any one 

time, one bus "master' can control the global bus. Each master 

will have a local bus and access to the global bus using priority 
3 0 bus arbitration. Local bus access does not require bus arbitration 

which maximizes processing bandwidth for each peripheral and 

minimizes global bus activity. 

Since the global bus is only utilized for data movement, a 

minimum amount oflocal bus using idle time is required for global 
35 bus arbitration, resulting in extremely fast data transfers. A 

master device can access another master's semaphores allowing 

remote maintenance and diagnostics. 
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Signal Description 
Address Bus (A23-A0) 

The 24 bit address bus signals are outputs from the current bus 
master which define the address of the byte (or most significant 
5 byte) to be transferred during a bus cycle. The address is valid 
while AS- is asserted. AO is the least significant bit. 

Data Bus (D15-D0) 

The 16 bit bidirectional, non-multiplexed data bus contains the 
10 data being transferred. Dynamic port sizing for 8 and 16 bit data 
transfers is supported. The slave device must assert DSACKl- or 
DSACKO- to size the port and terminate the bus cycle. DO is the 
least significant bit. 

15 Address Strobe (AS-) 

This active low signal generated by the active bus master 
signals the validity of both the address and many control signals. 
A pull-up resistor on the Controller is used to place this signal 
in a high logic level during idle periods on the global bus. Non- 
20 active bus masters must tri-state this signal. 

Data Strobe (DS-) 

This active low signal generated by the active bus master 
signals a slave device that data should be placed on the data bus 
25 during a read cycle or that data on the bus is valid for a write 
cycle. Non-active bus masters must tri-state this signal. 

Read / Write (R/W-) 

This signal is generated by the active bus master to indicate 
30 the direction of the data transfer on the bus. A logic one 
indicates that the master is reading from a slave device; a logic 
zero indicates a write to the slave device. 

Data and Size Acknowledge (DSACKl- , DSACKO- ) 
35 These two active low signals are asserted by the addressed 

slave device to terminate asynchronous data transfers and provide 
dynamic bus sizing. A pull-up resistor on the Controller is used 
to place these signals in a high logic level when not being 
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asserted by a slave device. Non-addressed slave devices must tri- 
state these signals. The following table describes these signals. 



DSACKl - DSACKO- RESULT 

5 11 Insert wait states in current cycle 

1 0 Cycle Complete: Port Size is 8 bits 

0 1 Cycle Complete: Port Size is 16 bits 

0 0 Not Valid 

10 Data Size (SIZEl. SIZEO) 

These signals are asserted by the current bus master and 
indicate the number of operand bytes that remain to be transferred 
in the current bus cycle . The following table describes these 
signals . 

15 

SIZE 1 SIZEO TRANSFER SIZE 

0 1 BYTE 

1 0 WORD 

1 1 THREE BYTE 

2 0 0 0 LONG WORD 

Read-Modif v-Write (RMW- ) 

This active low signal is generated by the current global bus 
master and is asserted to indicate to the addressed slave, that a 
25 read-modify-write operation is being executed. The slave global 

interface logic must prohibit the slave device from processing the 
memory location currently being addressed by the global master. 

Data Parity (PAR1,PAR0) 

3 0 The Data Parity signals are generated by the current global bus 

master for global memory write operations, and by the slave device 
during global bus read operations. PARO and PARI determine the 
parity of D7-D0 and D15-D8 respectively. Odd parity checking is 
used to verify data bus integrity. The addressed Slave device upon 

35 detecting a fault, will assert the Bus Error (BERR-) signal for the 
remainder of the current bus cycle. Read cycle parity faults will 
be determined in the global bus master and will cause exception 
processing . 
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Bus Error (BERR-) 

This active low signal is generated by a Slave device upon 

detecting a odd parity error on the global data bus. Upon 
detecting the assertion of BERR- , the current bus master will retry 
5 the operation and report the failure. 

End of Slot Interrupt (EOSINT-) 

This active low signal is generated by the System Controller 
to indicate the end of the current slot . The OTA Processor uses 
10 this signal to begin processing the newly received slot data (if 
available) . Other peripherals can use this signal to identify slot 
boundaries . 



OTA to Line Note Interrupt (LINE1NT-) 
15 This active low signal is generated by the OTA Processor to 

signal the Line Interface Processor that a "NOTE" has been written 
into memory and is available for processing. 

Line to OTA Note Interrupt (OTAINT-) 
20 This active low signal is generated by the LINE Interface 

Processor to signal the OTA Processor that a "NOTE" has been 
written into memory and is available for processing. 

Global Bus Request (BRx-) 
25 These active low signals indicate to the System Controller that 

a peripheral ( s) needs to become the bus master. This signal can 
be asserted at any time, but should be synchronized to the rising 
edge of GCLK. 

3 0 Global Bus Grant (Bqx-) 

These active low signals are generated by the System Controller 
in response to a valid Global Bus Request. This signal indicates 
to a peripheral device requesting access to the global bus that it 
may assume control of the bus following release of BGACK- by the 

35 current bus master. 

Global Bus Acknowledge (BGACK- ) 

This active low signal is generated by the current global bus 
master and indicates that the global bus is in use. BGACK- must 



BJMSDOCID: <WO 97i33S3A1_l_> 



wo 97/13353 PCT/US96/15590 

248 

remain asserted until all required bus cycles are complete. A 
pull-up resistor on the System Controller places BGACK- at a high 
logic level when the global bus is in the Idle state. 

Reset (Reset-) 

This active low signal is either generated by the System 
Controller or the Line Processor to initialize the Base Station. 
Reset must be asserted for a minimum of 590 GCLK cycles. 

Global Clock (GCLK) 

The Global (TED) MHZ Clock is generated on the System 
Controller- This clock is used to synchronize global bus timing 
and to provide an external system clock for peripheral devices . 

Link Clock (LKCLK) 

The 20 MHZ Link Clock is generated by the Master Radio and is 
used to derive all Link related clocks . 

Line Reference Clock (LNREFCLK) 

This 8kHz clock is generated by a designated Line Card and is 
used to varactor tune the Link Oscillator on each radio. This 
adjustment is required to keep the Digital Line Clock and the Link 
Clocks rate locked. 

Loop Strobe (LPSTRB-) 

This active low, 200ns signal is generated by the Master Radio 
and indicates the end of slot 31. This signal is synchronized to 
be 5Mhz, internally generated reference clock. The System 
ntroller uses this signal to reset the slot counter. 

Clock Svnc (CLKSYNC-) 
his active low, 50ns signal is generated by the Master Radio 
used to clear counters in the System Controller and slave 
lich provide the 5MHz and lOMHz timing clocks. This insures 
h peripheral's 5MHz and lOMHz clocks are synchronized. 
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Maqnitiude Clock Enable (r4AGEN-) 

This active low signal is generated by the Master Radio and is 
used to signal the System Controller that PCP Magnitude and RSSI 
data is to be clocked into the diversity controller. 

5 

PCP Magnitude Score (PCPMAGx) 

These signals are generated by each radio if the correlated PCP 
score is equal to, or greater than the PCP Threshold. If the 
correlated output is less than the threshold, no score is sent. 
10 This 6 Bit signal is padded to 8 bits and inverted prior to being 
sent to being shifted out. The System Controller uses these 
signals as a prime metric to determine which antenna to transmit 
back on. PCPMAGx is only valid while MAGEN- is asserted. 

15 Received Signal Strength Difference (RSSEDI TFx) 

These signals are generated by each radio and indicate the 
difference between the largest and smallest RSSI measurement. This 
8 bit signal is inverted prior to being shifted out. The System 
Controller uses these signals as a metric to determine which 

20 antenna to transmit back on. RSSIDIFx is only valid while MAGEN- 
is asserted. 

Transmit Enable (TXFENx-) 

One of these active low signals generated by the System 
25 Controller is used to select the radio needed to transmit during 
the next slot. Assertion of this signal will occur at Frame State 
TBD. 

Power Down (PWRDNx-) 

3 0 These active low signals are generated by the System Controller 

and are used to force a faulty circuit off the Global Bus. Once 
a circuit card is determined to be faulty, PWRDNx- is asserted. 
PWRDNx- is periodically negated by the System Controller the 
circuit card is asked to perform a Built In Test. This will allow 

35 faulty circuit card to be replaced and then automatically brought 
back into service if required. 
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Circuit: Card Slot ID (IDrO:4l) 

Each Circuit Card will have a five bit card slot ID number 
which is generated on the back plane. This unique card slot number 
will be used by the Circuit Card to determine it's global bus 
5 address. 

Global Memory Map 

The Global Address Bus is capable of addressing up to 16M of 
memory and/or registers. Each Circuit Card is assigned a portion 
10 of this address space. Local bus address space is not restricted 
to the amount of global space assigned to the Circuit Card and must 
be managed internally. 

Global Bus Arbitration 

15 The global system bus allows multiple devices the flexibility 

to share resources while operating independently within the 
device's local memory space. At any one time, one bus master can 
control the global bus. Each master will have access to the global 
bus using priority bus arbitration. Activity within the device's 

20 local memory space does not require bus arbitration. 

Global Bus access must be limited to less than lOOu sec per 
request. Each master's Global Bus Interface Logic (GBIL) is 
required to provide a Global Bus Timer. If global access exceeds 
lOOu sec, the GBIL will terminate the Global Bus cycle and release 

25 the Global Bus. After releasing the Global Bus, the GBIL can again 
request access to the global bus. 

System Controller 

The System Controller manages the priority bus arbitration 
3 0 logic. When two or more devices attempt to become the bus master 
at the same time, the one having the highest priority will become 
the bus master first. The System Controller can be programmed to 
prevent any device from accessing the global bus. This feature can 
be used to prevent faulty devices or shadow redundant circuit cards 
3 5 from accessing the global bus. The following sequence illustrates 
the global bus arbitration protocol: 
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1) A device asserts BR- (Bus Request) . 

2} The System Controller asserts BG- (Bus Grant) to 
indicate to the device requesting access that it can 
claim the bus when released by the current bus master. 

3) Once a device has received BG- , it monitors BGACK- (Bus 
Grant Acknowledge) to determine when the current bus 
master is no longer requiring the global bus. The 
requesting device then asserts BGACK- to assume bus 
mastership . 



BG- may be asserted at any time during a bus cycle or between 
bus cycles. BG- is asserted in response to BR- . When a device 
assumes bus mastership, it asserts BGACK- and maintains BGACK- 
during the entire bus cycle (or cycles) for which it requires 

15 the global bus. The following conditions must be met for a 

device to assume mastership of the bus through the normal bus 
arbitration procedure: 1) it must have received BG- through the 
arbitration process, and 2) BGACK- must be inactive, indicating 
that no other bus master is claiming ownership of the global 

20 bus. 

Global to Local Bus Access 

Global devices requiring access to a slave device's local bus 
must use a special arbitration/semaphore technique. The requesting 
25 Global device must use the following sequence to gain control of 
another devices local bus . 

1) Requesting Device gains control of Global Bus. 

2) Requesting Device writes access request byte to slave 
30 circuit card's "Local Access Request Register". 

3) Requesting Device releases Global Bus for a minimum of 
one arbitration cycle. (Verify BGACK- is negated for a 
minimum of one GCLK cycle) This will allow the slave 
circuit card to complete a pending Global Bus Access 

35 before being forced to relinquish it's local bus. 

4) Requesting Device gains control of Global Bus. 

5) Requesting Device reads access grant byte from slave 
circuit card's "Local Access Grant Register", 
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If the slave has granted access to the requesting 
device, the requesting device may proceed. Upon access 
completion, the requesting device must clear the "Local 
Access Request Register" . 

The slave device will clear the Local Access Grant 
Register following the clearing of the "Local Access 
Request Register" . 

Global Data Bus Parity 

10 Odd Parity bits PARI and PARO , are associated with D15-D8 and 

D7-D0 respectively, and are used to' help verify data integrity on 
the Global Data Bus. These Data Parity signals are generated by 
the current global bus master for global memory write operations, 
and by the slave device during global bus read operations, 

15 During global write operations, the global bus master will 

drive the parity signals, one for each byte. The addressed slave 
device, will evaluate the parity of the data on the global data bus 
based on the port size it is capable of supporting and the size of 
the operand being written to it. For example, if a 16 bit word is 

20 written to a slave device that is only capable of supporting 8 bits 
of data at a time, the slave will only evaluate the parity of D15- 
D8 . If the slave device can support a 16 bit transfer, each byte 
of data will be tested to determine the validity of the operand. 
Upon detecting a fault, the slave device will assert the Bus Error 

25 (BERR-) signal for the remainder of the current bus cycle. The 

global bus master will log the data bus error and can retry the 
operation. 

During global bus read operations, the addressed slave device 
will set the parity bit (s) either according to it's port size (for 

30 an 8 bit port) , or the size of the operand transfer being 
requested. For example, if a word transfer is requested by the 
global bus master, and the slave device is an 8 bit port, only PARI 
is actively driven based on data byte D15-D8. The master device 
will verify the integrity of the received operand based on the port 

35 size of the addressed slave. If a global bus error is detected, 
the global bus master will log the bus error and can retry the 
transfer . 



6) 



7) 
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System Controller 

The System Controller is responsible for managing the Base 
Station. This includes moving and qualifying data between the 
radios and peripheral devices. T^tenna diversity is controlled by 
5 the System Controller, as well as system fault and configuration 
management. The System Controller also manages the priority bus 
arbitration logic. The following paragraphs describe in more 
detail. System Controller requirements. 

10 Local Bus 

The System Controller is capable of addressing up to 4G Bytes 
of memory. High speed SRAM is used to provide no wait state 
working storage. Programmable logic firmware contained in FLASH 
memory is also accessible from the Local Bus, 

15 

Global Bus Access 

The Global Bus uses 24 address line to address up to 16M Bytes 
of memory. Since the addressable memory space of the System 
Controller far exceeds the addressable memory space of the Global 

20 Bus, programmable chip selects in the MC68341 will be used to 
indicate Global access. The Global Bus Interface Logic on the 
System Controller will monitor chip select (s) TBD to determine if 
Global Bus access is required. Upon detecting Global Bus access, 
the Global Bus Interface Logic will assert BR- and will negate 

25 DSACKx- to force wait states to be generated by the MC68341. When 
Global Bus Mastership is acquired, the Global Bus Interface Logic 
enables the MC68341 to drive the bus and turns control of the 
DSACKx- signals over to the addressed slave device. The slave 
device is now responsible for data bus sizing and cycle 

30 termination. Upon completion of the Global Bus access, the Global 
Bus Interface Logic will release BGACK- and will remove the MC6 8341 
from the bus. 

Configuration Registers 
35 The System Controller's Global Interface Logic uses read/write 

configuration registers to provide a flexible interface to the 
Global Bus . 
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Global Configuration Register 

The Global Configuration Register is undefined in the System 
Controller . 

5 Revision Register 

This register can be read by a Global Bus Master to determine 
the current hardware, software, and firmware configuration. Bit 
definitions are as follows: 

10 Bit Position Description 

B[3:0] Circuit Card Rev. Number 

B[9:4] Firmware Rev. Number 

B [15: 101 Software Rev, Number 

15 Health Register 

The Health Register is used by the System Controller to 
indicate operational and Built in Test (BIT) status. 

Local Access Reauest Register (LARR) 
20 A Global Device requiring access to the System Controller's 

local bus, must write the appropriate request byte into the LARR. 
Upon detecting a request, the Global Interface Logic will force the 
68341 to relinquish the local bus. After the requesting device has 
finished accessing the local bus, it must clear the LARR. 

25 

LARR Description 

52 hex Local Access Request 

Local Access Grant Register (LAGR) 

30 The Access Grant Register is read by a Global device requesting 

access to the System Controller's Local bus. The Global Bus 
Interface Logic will update this register in response to a Local 
Access Request and clear it following a Global device's completed 
access. A watchdog timer is used to clear the Local Access Grant 

3 5 Register if the requesting Global device does not claim the Local 
bus within TBD msec . 
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lAGR DescriTDt ion 

00 hex Local Access Disable 

47 hex Local Access Grant 



5 Reset System Configuration 

Following a system Reset, the System Controller will determine 
the current configuration of the base station by polling each 
circuit card. If the circuit card fails to respond or responds 
incorrectly, within TBD GCLK cycles, it is not considered a usable 

10 resource and is ignored. The System Controller will periodically, 
re-evaluate the current configuration to allow circuit card 
replacement during base station operation. Each circuit card 
defaults to a slave or non-primary configuration until such time 
as the System Controller commands a change of state. The System 

15 Controller will select a radio to supply the Master Link Timing and 
will designate the primary OTA and Line Processors. 

Radio / Link Timing Management 

The rest of the base station, including all remaining slave 

20 radios, either directly or indirectly receive timing information 
from the master radio. If a Link timing failure were to occur, the 
System Controller can select a different master radio to provide 
Link Timing. Refer to "Radio Interface Circuit Card User Interface 
Document, Version 2.0" for more detailed information. 

25 The master radio provides a signal called. LPSTRB- to indicate 

the end of the slot 31. The System Controller uses this signal to 
reset it's slot counter and to initialize Frame State Counter. The 
Frame State Counter is used by the System Controller to determine 
system service timing. 

30 During a "Poll Frame" the mobile station does not send a Power 

Control Pulse (PCP) prior to the base transmission. In this case, 
the System Controller knows in advance, which radio's transmit 
buffer is to be loaded. Once a mobile station is operating in 
"Traffic Mode", the System Controller monitors the quality of the 

35 received PCP and determines which radio will be used to transmit 
the next frame to that mobile station. Data to be transmitted, is 
loaded into the transmitting radio's transmit buffer prior to Frame 
State TBD and must be read from the radio's receive buffer 
following Frame State TBD. 
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Antenna Diversity 

In a multi-radio base station, the System Controller is 
responsible for dynamically determining which radio will be used 
to transmit to the mobile station. During Non-Poll frames, the 
5 mobile station will transmit a PCP at the beginning of the frame . 
The base will receive the PCP on up to four radios from the mobile 
station and will sample the quality and signal level of the PCP to 
help determine which radio to use. Based on the assumption that 
transmit and receive paths are symmetric if the frequencies are the 

10 same and if there is minimal turn around time, the System 
Controller determines which radio to transmit on. Received signal 
strength, historical and statistical information will also be used 
to help, qualify a radio for transmission. Information such as no 
valid mobile station responses received to a General Poll when a 

15 particular radio transmits could indicate that the radio has a good 
receiver with a bad transmitter. The System Controller could 
disqualify the radio with the bad transmitter from diversity 
transmit consideration . The receiver portion of the faulty radio 
may be still provide useful information. 

20 

Link Data Control 

The System Controller is responsible for moving; 1) protocol 
data between the radios and the OTA Processor (s) , and 2) voice/data 
between the radios and the Line Card(s) . Using the Frame State 

2 5 Count to generate System Controller internal interrupts , data is 

either moved into or out of the radio (s) . At the end of the slot, 
an interrupt is generated by the System Controller to indicate to 
the OTA Processor and Line Cards, that they may begin processing 
data from the last slot. This active low signal is known as the 

3 0 End of Slot Interrupt (EOSINT) and is asserted for a minimum of TBD 

GCLK cycles . This signal can be used by other peripherals to 
identify slot boundaries if required . 

Arbitration Logic 

3 5 The System Controller is responsible for managing the Global 

Bus Arbitration Logic . Each circuit card capable of becoming a 
global bus master has dedicated BR- and BG- signals. Dedicated 
signals allow the arbitration logic to provide priority bus access 
and bus access restriction. lOOu sec prior to the end each slot, 
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the System Controller restricts access grants to the global bus 
only to the System Controller. Since each master is limited to 
lOOu sec bus access, the radio link service is guaranteed not to 
be delayed by another Global Bus Master "tying up the bus". In a 
redundant configuration, a faulty circuit card could continually 
assert BR- or EG- . If these signals were shared between circuit 
cards, this type of failure would totally bring down the base 
station. Upon determining that a circuit card is faulty, it's 
arbitration logic can be disabled allowing normal Global Bus 
activity by the rest of the system to continue. 

Global Memorv 

The System Controller Circuit Card provides two Meg Bytes of 
Global DRAM and all the required bus interface logic. Peripherals 
needing access to Global Memory, including the System Controller, 
must first gain mastership of the Global Bus using the Global Bus 
arbitration protocol. 

OTA Processor 

The OTA Processor is responsible for managing the Over-The-Air 
Protocol. At the end of each slot, the OTA Processor is 
interrupted by the System Controller using the EOSINT signal. The 
OTA Processor will read the OPCOMP Register in Local Dual -Port 
memory to determine which slot to process. There are two frames 
of data per slot, one for transmit and the other for receive. 
Frames are mapped in Dual -Port memory using the slot number and 
frame type. The base station can support up to two OTA Processors 
which can. be -configured to provide task sharing, shadow 
redundancy, or stand alone operation. Each OTA Processor is 
identical and will use the Circuit Card Slot ID to determine Global 
Bus memory map location decoding. 

Local Bus 

The OTA Processor is able to directly address I Meg Byte of 
memory and/or registers. 

Global Bus Access 

The Global Address Bus uses 24 address lines to directly access 
up to 16M Bytes. The OTA Processor (s) is only capable of directly 
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addressing IM Bytes of combined Local and Global memory. Global 
chip selects , GCSl and GCS2 generated by the 80186 , are used to 
define Global Bus Memory blocks. GCSl is used to select "Notes" 
Dual -Port space and GCS2 points to Global DRAM. The Global Inter- 
face Logic on the OTA Processor, monitor's GCSl and GCS2 to 
determine if the memory being addressed is global. Assertion of 
either signal will cause the Global Bus Interface Logic to suspend 
the current 80186 bus cycle and begin Global Bus Arbitration. When 
the OTA Processor becomes the Global Bus Master, Page Registers in 
the Global Interface Logic will Map the most significant address 
bits onto the Global Bus and the 80186 is allowed to complete the 
current bus cycle. These Page Registers are initialized at power- 
up and can be modified at any time by the 80186 to point to 
different address blocks corresponding to either GCSl or GCS2 , The 
Global Bus Interface Logic limits continuous Global Bus access to 
lOOu sec. Block transfers greater than lOOus rearbitrate for the 
Global Bus. 

Configuration Registers 

The OTA Processor's Global Interface Logic uses read/write 
configuration registers to provide a flexible interface to the 
Global Bus. Table 3.0 defines these registers, and their location 
in the OTA Processor's local memory map. Refer to "Version 2.0 OTA 
Processor User Interface Document" for more information. 

Global Configuration Register 

The Global Configuration Register is configured by the System 
Controller and is used to control the operational mode of the OTA 
Processor. Following a system Reset, the Global Interface Logic 
defaults to the Idle mode. The System Controller will determine 
which, if multiple OTA Processors are available, OTA Processor is 
to be configured as Active. In the Active mode, the OTA Processor 
will manage the Over-The-Air prptocol . 

While in the Shadow mode, the OTA processor's Global Bus access 
is restricted. The OTA Processor can function as though it was 
actually servicing incoming interrupts, but is not permitted access 
the Global Bus or to generate OTA to Line Note Interrupts. These 
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restrictions are controlled by the Global Interface Logic on the 
circuit card and are transparent to the 80186. 

MODE PATTERN DESCRIPTION 

5 IDLE 00 hex Suspend Operation 

ACTIVE 4 2 hex Run 

SHADOW 53 hex Run in Back Up Mode 

BIT 95 hex Self Test 

10 Revision Register 

This register can be read by a Global Bus Master to determine 
the current hardware, software, and firmware configuration. Bit 
definitions are as follows: 

Bit Position Description 
15 B[3:0] Circuit Card Rev. Number 

B[9:4l Firmware Rev. Number 

B [15: 101 Software Rev. Number 

Health Register 

20 The Health Register is used by the OTA Processor to indicate 

operational and Built in Test (BIT) status. The System Controller 
will poll this register periodically to determine the current 
status of the OTA Processor. 

25 Local Access Request Register (LARR) 

A Global Device requiring access to the OTA Processor's local 
bus, must write the appropriate request byte into the LARR. Upon 
detecting a request, the Global Interface Logic will force the 
80186 to relinquish the local bus. After the requesting device has 

30 finished accessing the local bus, it must clear the LARR. 

LtARR Description 

52 hex Local Access Request 

3 5 Local Access Grant Register (LAGR) 

The Access Grant Register is read by a Global device requesting 
access to the OTA Processor's Local bus. The Global Bus Interface 
Logic will update this register in response to a Local Access 
Request and clear it following a Global device's completed access. 
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A watchdog timer is used to clear the Local Access Grant Register 
if the requesting Global device does not claim the Local bus within 
TBD msec. 

5 LAGR Description 

00 hex Local Access Disable 

4 7 hex Local Access Grant 

"Notes" Dual Port Page Register 
10 This 9 bit read/write register is initialized by the System 

Controller and is used as a base page address register. The 
contents of this Register in conjunction with the lower order 15 
address bits from the 80186, point to the active Line Interface 
Processor's "Notes" Dual Port. The maximum page size is 16k bytes. 

15 

Soft Reset Register (SRR) 

This 8 bit write only register is used to force a circuit card 
reinitialized. Any Global Bus Master can write to this register. 

20 SRR Description 

6 9 hex Soft Reset 

Dual Port Memory Map 

The high speed Dual Port Memory is used to buffer Over -The -Air 
25 and status/control data. The System Controller will write data 
received by the radios into Dual Port Memory. The OTA Processor 
will evaluate the received data and will write the response into 
the Dual Port's transmit buffer for that slot. The OPCOMP Register 
within the Dual Port indicates to the OTA Processor which air slot 
30 buffer is to be processed. 

Power Down Signal (PWRDNx-) 

The Power Down signal is generated by the System Controller to 
remove a faulty circuit card from service. This active low signal 
35 will force the faulty circuit card off the Global Bus and prevent 
it from generating arbitration requests, clocks or interrupts. 
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Line Interface Processor 

The Line Interface Processor is responsible for managing the 
signaling interface between the OTA Processor and the backhaul Line 
Card(s). "Notes" messages will be interpreted by the Line 
5 Interface Processor and either passed toward the network or acted 
upon directly. The action required depends upon the type of Line 
Card(s) installed in the base and if the Line Card(s) is connected 
directly to the network. The Line Interface Processor and the Line 
Card(s) support the standard "Notes" interface within the base 
10 station which provides Line Card "Transparency" to the rest of the 
system. Backhaul protocols such as ISDN-BRI or the Omnipoint 
Proprietary Interface will by supported by the Line Interface 
Processor. Future integration could combine the Line Interface 
Processor and the Line Card{s) . 

15 

Local Bus 

The Line Interface Processor is based on the Motorola MC68360, 
Quad Integrated Communications Controller and is capable of 
addressing up to 4G Bytes of memory. Within the Line Interface 
20 Processor's Local bus, 32 bit data transfers are supported. 

Global Bus Access 

The Global Bus uses 24 address line to address upto 16M Bytes 
of memory. Since the addressable memory space of the Line 

25 Interface Processor far exceeds the addressable memory space of the 
Global Bus, programmable chip selects in the MC68360 will be used 
to indicate Global access. The Global Bus Interface Logic on the 
Line Interface Processor will monitor chip select (s) TBD to 
determine if Global Bus access is required. Upon detecting Global 

30 Bus access, the Global Bus Interface Logic will assert BR- and will 
negate DSACKx- which forces wait states to be generated by the 
MC68360. When Global Bus Mastership is acquired, the Global Bus 
Interface Logic enables the MC68360 to drive the bus and turns 
control of the DSACKx- signals over to the addressed slave device . 

35 The slave device is now responsible for data bus sizing and cycle 
termination. Upon completion of the Global Bus access, the Global 
Bus Interface Logic will release BGACK- and will remove the MC68360 
from the bus. The Global Bus Interface Logic limits continuous. 
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Global Bus access to lOOu sec. Block transfers greater than lOOus 
re-arbitrate for the Global Bus, 



Configuration Registers 

The Line Interface Processor's Global Interface Logic uses - 
read/write configuration registers to provide direct control/status 
information to-the Global Bus. 



10 



15 



20 



25 



Global Configuration Register 

The Global Configuration Register is configured by the System 
Controller and is used to control the operational mode of the Line 
Interface Processor. Following a system Reset, the Global 
Interface Logic defaults to the Idle mode. The System Controller 
will determine which Line Interface Processor is to be configured 
as Active. Multiple active Line Interface Processor circuit cards 
can be supported. In the Active mode, the Line Interface Processor 
will manage the "Notes" interface and backhaul protocol. 

While in the shadow mode, the Line Interface Processor's Global 
Bus access is restricted. The Line Interface Processor can 
function as though it was actually servicing incoming interrupts, 
but is not permitted access the Global Bus or to generate Line to 
OTA Note Interrupts. These restrictions are controlled by the 
Global Interface Logic on the circuit card and are transparent to 
the MC68360. 



30 



MODE 

IDLE 

ACTIVE 

SHADOW 

BIT 



PATTERN 
00 hex 
41 hex 
53 hex 
95 hex 



DESCRIPTION 
Suspend Operation 
Run 

Run in Back Up Mode 
Self Test 



35 



Revision Register 

This register can be read by a Global Bus Master to determine 
the current hardware, software, and firmware configuration. Bit 
definitions are as follows: 
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Bit Position Description 

B[3:0] Circuit Card Rev. Number 

B[9:4] Firmware Rev. Number 

B[15:10] Software Rev. Number 

5 

Health Register 

The Health Register is used by the Line Interface Processor to 
indicate operational and Built in Test (BIT) status. The System 
Controller will poll this register periodically to determine the 
10 current status of the Line Interface Processor. 

Local Access Request Register (LARR) 

A Global Device requiring access to the Line Interface 
Processor's local bus, must write the appropriate request byte into 
15 the LARR. Upon detecting a request, the Global Interface Logic 

will force the MC68360 to relinquish the local bus. After the 
requesting device has finished accessing the local bus, it must 
clear the LARR. 

2 0 LARR Description 

52 hex Local Access Request 

Local Access Grant Register (LAGR) 

The Access Grant Register is read by a Global device requesting 
25 access to the Line Interface Processor's Local, bus. The Global Bus 
Interface Logic will update this register in response to a Local 
Access Request and clear it following a Global device's completed 
access. A watchdog timer is used to clear the Local Access Grant 
Register if the requesting Global device does not claim the Local 

3 0 bus within TBD msec. 

LAGR Description 

0 0 hex Local Access Disable 

4 7 hex Local Access Grant 



35 



Local Access Page Register (LAPR) 

This 14 bit read/write register is written to by a Global 
device requiring access to the Line Interface Processor's Local 
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Bus. These bit provide the most significant local address bits and 
provide direct access to 512k byte pages. 



"Notes" Dual Port Page Register 
5 This 9 bit read/write register is initialized by the System 

Controller and is used as a base page address register. The 
contents of this Register in conjunction with the lower order 15 
address bits from the MC68360, point to the active OTA Processor's 
"Notes" Dual Port. The maximum page size is 32k bytes. 

10 

"Notes" Dual Port Memorv Map 

The high speed 3 2k byte Dual Port Memory is used to buffer 
"Notes " messages between the OTA Processor and the Line Interface 
Processor . 

15 

Power Down Signal (PWRDNx-) 

The Power Down signal is generated by the System Controller to 
remove a faulty circuit card from service. This active low signal 
will force the faulty circuit card off the Global Bus and prevent 
20 it from generating arbitration requests, clocks or interrupts. 

Line Card 

The Line Card(s) connect the base station either directly or 
indirectly to the network. Different Line Card type's provide the 
25 specific hardware /software capabilities required to connect the 
Omnipoint Base Station to various interfaces and protocols . 
Multiple Line Cards are supported by the Global Bus and can be used 
for task sharing, redundant or stand alone operation. A standard 
Line Card interface is used in the base station in an attempt to 

30 minimize the impact changing a Line Card type has on the rest of 
the system. Version 2.0 Line Cards are considered to be slaves, 
that is, they are not capable of accessing Global resources. 
Future integration could combine the Line Card and Line Interface 
Processor functionality, which could create a Line Card capable of 

35 Global Bus Mastership. Refer to the Line Card specific "Version 
2.0 Users Interface Document" for more detained interface 
inf ormat ion . 
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Local Bus 

Local Bus architecture can vary depending on Line Card type. 
Each Line Card will have reprogrammable logic and software FLASH 
memory to the extent possible. Global devices have access to the 
5 Line Card's Local Bus and must read the Global "Type" Register to 
determine the circuit card specific interface requirement. 

Global Bus Access 

Version 2.0 Line Cards are not able arbitrate access to the 
10 Global Bus and are therefore refereed to as "Slaves". Slave 
devices monitor the Global Address Bus and are prepared to respond 
to any external Global Bus Master access request . Slave devices 
are responsible for data bus sizing and cycle termination. 

15 Configuration Registers 

The Line Card's Global Interface Logic uses read/write 

configuration registers to provide direct control/status 
information to the Global Bus. 

20 Global Configuration Register 

The Global Configuration Register is configured by the System 
Controller and is used to control the operational mode of the Line 
Card. Following a system Reset, the Global Interface Logic on the 
Line Card defaults to the Idle mode. The System Controller will 

25 determine which Line Card(s) are to be configured as Active. 

Multiple Line Cards can be in the Active mode at any one time. 
While in the Idle mode, the Line Card's network/trunk servicing is 
suspended. 



30 



35 



MODE 

IDLE 

MASTER 

SLAVE 

BIT 

LOOPBACK 



PATTERN 
00 hex 
4D hex 
53 hex 
95 hex 
24 hex 



DESCRIPTION 
Suspend Operation 
Run, Provide LREFCLK 
Run 

Self Test 

Bypass Vocoder, Loop HS 
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Revision Register 

This register can be read by a Global Bus Master to determine 
the current hardware, software, and firmware configuration. Bit 
definitions are as follows: 

5 

Bit Position 
B [3 :0] 
B [9:4] 
B[15: 10] 

10 

Health Register 

The Health Register is used by the Line Card Processor to 
indicate operational and Built in Test (BIT) status. The System 
Controller will poll this register periodically to determine the 
15 current status of the Line Card . 

Local Access Request Register (LARR) 

A Global Device requiring access to the Line Card's local bus, 
must write the appropriate request byte into the LARR. Upon 
20 detecting a request, the Global Interface Logic will force the Line 
Card to relinquish the local bus. After the requesting device has 
finished accessing the local bus, it must clear the LARR. 

LARR Description 
25 52 hex Local Access Request 

Local Access Grant Register (LAGR) 

The Access Grant Register is read by a Global device requesting 
access to the Line Card's Local bus. The Global Bus Interface 
3 0 Logic will update this register in response to a Local Access 
Request and clear it following a the Global device's completed 
access. A watchdog timer is used to clear the Local Access Grant 
Register if the requesting Global device does not claim the Local 
bus within TBD msec. 

35 

LAGR Description 

00 hex Local Access Disable 

4 7 hex Local Access Grant 



Description 

Circuit Card Rev. Number 
Firmware Rev. Number 
Software Rev. Number 
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Line Card Type Register (LCTR) 

This 8 bit register is loaded by the Line Card upon circuit 
card initialization. These bits can be read by any Global Bus 
Master to determine the type of Line Card currently installed. The 
5 following table lists possible Line Card Types. 



LINE CARD TYPES 





Type 


(hex) Description 




00 


Analog Loop Start 


10 


10 


DSl w/transcoder 




11 


DSl no transcoder 




12 


DSl compressed 




20 


HDSL w/transcoder 




21 


HDSL no transcoder 


15 


22 


HDSL compressed 




30 


ISDN-BRI w/transcoder 




31 


ISDN-BRI no transcoder 



Line Card Dual Port Memory Map 
20 The high speed 8k byte Dual Port Memory is used to buffer 

voice, data, and "Notes" messages between the connecting trunk and 
the base station. Voice and data frames are moved between the Line 
Card Dual Port and radio (s) by the System Controller using the 
Standard Line Interface. 

25 

Power Down Signal (PWRDNx- ) 

The Power Down signal is generated by the System Controller to 
remove a faulty circuit card from service. This active low signal 
will force the faulty circuit card off the Global Bus and prevent 
30 it from generating arbitration requests, clocks or interrupts. 

Radio Interface 

The Radio Interface Circuit Card is responsible for managing 
the interf ace between the Radio and the rest of the base station. 
3 5 The base station is capable of supporting from one to four radios, 
which provides antenna diversity and redundant/back up operation. 
The Radio Interface Circuit Card is considered to. be a "Slave" on 
the Global Bus and can not arbitrate for Global Bus Mastership. 
The System Controller will designate one radio to provide Master 
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Link Timing by setting the it's Global Configuration Register to 
the Master Mode. The Master Link Timing Radio will provide the 
Link Clock and associated timing signals necessary to maintain a 
synchronized radio link. The System Controller can redesignate the 
5 Master Link Timing Radio upon demand. Refer to Version 2.0, Radio 
Interface Circuit Card User Interface Document for more 
information . 

Local Bus 

10 The Radio Interface Circuit Card has an internal 8 bit "Local" 

bus which connects the Radio Interface Logic to Dual Port and Flash 
memory. Global devices have access to the Radio Interface Circuit 
Card's Local Bus, which provides a means to reprogram the FLASH 
memory. Access to the Radio Interface Circuit Card's Local Bus is 

15 negotiated using semaphores. 

Global Bus Access 

Version 2 . 0 Radio Interface Circuit Cards are not able 
arbitrate access to the Global Bus and are therefore refereed to 
20 as "Slaves". Slave devices monitor the Global Address Bus and are 
prepared to respond to. any external Global Bus Master access 
request. Slave devices are responsible for data bus sizing and 
cycle termination . 

25 Configuration Registers 

The Radio Interface Circuit Card's Global Interface Logic uses 
read/write configuration registers to provide direct control /status 
information to the Global Bus. 

3 0 Global Configuration Register 

The Global Configuration Register is configured by the System 
Controller and is used to control the operational mode of the Radio 
Interface Circuit Card(s). Following a system Reset, the Global 
Interface Logic on the Radio Interface Circuit Card defaults to the 

35 Idle mode. While in the Idle mode, the Radio Interface Circuit 
Card will not transmit or enable the Master Link Timing signals 
onto the bus. When the System Controller has completed programming 
the required configuration registers it will signal the Radio 
Interface Circuit Card to enter the "RUN" mode by writing the. Run 
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10 



15 



20 



Enable pattern in to the Global 
configured into the RUN mode, the 
begin operation . 



MODE 

IDLE 

MASTER , Varactor 
Adjust 

SLAVE, Varactor 
Adjust 

MASTER, No 
Varactor Adj 
SLAVE, No Varactor 
Adj 
BIT 



PATTERN 
00 hex 
4D hex 



53 hex 



4C hex 



52 hex 



4 2 hex 



Configuration Register. Once 
Radio Interface Circuit can to 



DESCRIPTION 
Suspend Operation 
Run, Provide Master Link 
Timing Varactor tune 
oscillator 

Run, use external Link 
Timing Varactor tune 
oscillator 

Run, Provide Master Link 
Timing No Varactor tuning 
Run, use external Link 
Timing No Varactor tuning 
Self Test, Do Not 
Transmit 



Revision Register 

This register can be read by a Global Bus Master to determine 
the current hardware and firmware configuration. Bit definitions 
are as follows: 



Bit Position 

B[3:0] 

B [9:4] 



Description 

Circuit Card Rev. Number 
Firmware Rev, Number 



2 5 Health Register 

The Health Register is used by the Line Card Processor to 
indicate operational and Built in Test (BIT) status. The System 
Controller will poll this register periodically to determine the 
current status of the Radio Interface Circuit Card. 

30 

Local Access Reauest Register (LARR) 

A Global Device requiring access to the Line Card's local bus, 
must write the appropriate request byte into the LARR. Upon 
detecting a request, the Global Interface Logic will force the 
35 Radio Interface Circuit Card to relinquish the local bus. After 
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the requesting device has finished accessing the local bus, it must 
clear the IxARR. 

LARR Description 
52 hex Local Access Request 

Local Access Grant Register (LAGR) 

The Access Grant Register is read by a Global device requesting 
access to the Radio Interface Circuit Card's Local bus. The Global 
Bus Interface Logic will update this register in response to a 
Local Access Request and clear it following a Global device's 
completed access. A watchdog timer is used to clear the Local 
Access Grant Register if the requesting Global device does not 
claim the Local bus within TBD msec. 

LAGR DescriTDtion 

GO hex Local Access Disable 

4 7 hex Local Access Grant 

2 0 Dual Port Memorv Map 

High speed 16k byte Dual Port Memory is located on the Radio 
Interface Board and is used to buffer incoming and outgoing data, 
commands, status, and radio setups. Data to be transmitted is 
loaded in to the dual port prior to the assertion of TXFENx- . As 

25 data is received from the mobile station it is loaded into the Dual 
Port receive buffer. At the end of the slot,, the System Controller 
moves the data from the selected radio to the OTA Processor and/or 
the Line Cards. Link parameters such as correlator codes, and 
frequencies are also loaded into the Dual Port. 

30 

Powe r Down S i ana 1 ( PWRDNx - > 

The Power Down signal is generated by the System Controller to 
remove a faulty circuit card from service. This active low signal 
will force the faulty circuit card off the Global Bus and prevent 
35 it from generating arbitration requests, clocks or interrupts. 

Master Link Timing 

The designated Master Radio is responsible for providing the 
Master Link Timing Signals for each base station. These signals 
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include, the 20 MHZ Link Clock LKCLK, LPSTRB- and CLKSYNC- . Using 
these signals, the System Controller and the Slave Radios can all 
stay in lock step with each other. 

5 Link Clock. 2 0MM (LKCLK) 

The Master Radio is responsible for providing the 20MH2 
reference clock to the System Controller and Slave Radios. 
Internal 5MHz and lOMHz reference clocks will be developed from the 
Master Link Clock. Every radio will varactor tune its 20MHz clock 
10 based on the 8kHz LNREFCLK. 

Line Reference Clock (LNREFCLK) 

The Line Reference Clock is an SkHz signal generated by a 
designated Line Card and is used rate lock the radio oscillators 
15 to the digital network and to frequency lock each radio's clock. 

If the Line Card does not connect to a digital network, it will use 
the 5MHz clock from the System Controller to develop the 8kHz 
reference . 

2 0 Loop Strobe (LPSTRB- ) 

This active low, 200ns signal is generated by the Master Radio 
and indicates the .end of slot 31. This signal is synchronized to 
the 5MHz, internally generated reference clock. The System 
Controller uses this signal to reset the slot counter. 

25 

Clock Svnc (CLKSYNC-) 

This active low, 50ns signal is generated by the Master Radio 
and is used to clear counters in the System Controller and slave 
radio which provide the 5MHz and lOMHz timing clocks. This insures 
30 that each peripheral's 5MHz and lOMHz clocks are synchronized. 

Received Signal Quality Signaling 
Each radio upon receiving the PCP signal from a Mobile Station will 
attempt to determine the relative signal quality of the 
35 transmission. This information is sent to the System Controller 
where the determination is made as to which antenna is to be used 
for the next base transmission. 
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Magnitude Clock Enable (MAGEN-) 

This active low signal is generated by the Master Radio and is 
used to signal the System Controller that PCP Magnitude and RSSI 
data is to be clocked into the diversity controller, 

5 

PCP Magnitude Score (PCPMAGx) 

These signals are generated by each radio if the correlated PCP 
score is equal to, or greater than the PCP Threshold, If the 
correlated output is less than the threshold, no score is sent. 
10 This 6 bit signal is padded to 8 bits and inverted prior to being 
sent to being shifted out. The System Controller uses these 
signals as a prime metric to determine which antenna to transmit 
back on, PCPMAGx is only valid while MAGEN- is asserted. 

15 Received Signal Strength Difference (RSSIIDIFx) 

These signals are generated by each, radio and indicate the 
difference between the largest and smallest RSSI measurement. This 
8 bit signal is inverted prior to being shifted out. The System 
Controller uses these signals as a metric to determine which 

20 antenna to transmit back on. RSSIDIFx is only valid while MAGEN- 
is asserted. 

Base Station Software Technical Requirements 

This section presents a list of Base Station software 
25 functional parameters. 

Operational Parameters 

The software will control the following operations, performed by 
30 the OTA processor. 

1) The OTA processor boot code shall perform a self test, the 
duration of which shall not exceed 30 seconds and which does not 
require intervention from the Line Card. 

35 

2) The OTA processor shall support the download and activation of 
operational code via the dbug port or via the I Interface. 
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3) The OTA processor shall perform a soft reset on itself on 
receipt of a request from the Line Card. 

4) For the first release, the OTA processor will only support a 
5 single 16 time slot radio path. There is a future requirement to 

support dual radio paths. 

5) The OTA processor shall fully support the Omnipoint NOTES 
protocol . 

10 

6) The OTA processor shall fully support the Omnipoint OTA 
protocol . 

7) The OTA processor shall transfer messages from the Line Card via 
15 Dual Port RAM. 

8) The OTA processor shall transfer messages to the Line Card via 
Dual Port RAM. 

20 9) The OTA processor shall transfer messages from the Radio Line 
Card via Dual Port RAM. 

10) The OTA processor shall transfer messages to the Radio Line 
Card via Dual Port RAM. 

25 

11) The OTA processor shall send OAM+P messages to the Line Card 
via Dual Port RAM. 

12) The OTA processor shall receive 07VM+P messages from the Line 
3 0 Card via Dual Port RAM. 

13) The OTA processor shall send OAM+P messages to the Radio Line 
Card via Dual Port RPM. 

3 5 14) The OTA processor shall receive OAM+P messages from the Radio 
Line Card via Dual Port RAM. 

15) The OTA processor shall provide a mechanism that will 
initialize, operate, reconfigure and shut down managed objects. 



JNSDOCID; <WO 9713353A1. 1. > 



wo 97/13353 PCT/US96/15190 

274 

16) The OTA processor shall detect fault conditions and report to 
the Line Card OAM&P. 

17) The OTA processor shall support the gathering of statistical 
5 data to measure the performance of the system. 

18) The OTA processor shall support the Administrative state change 
request from the Line Card OAM&P, 

10 19) The OTA processor shall perform diagnostics tests and report 
the results to the Line Card OAM&P. 

20) The OTA processor shall receive SMS point to point messages 
from the Line Card for transmission to the Radio Line Card. 

15 , 

21) The OTA processor shall provide a transport mechanism for all 
messages associated with Encryption, but will not actually support 
encryption of the bearer channel. 

20 22) The OTA processor shall perform DTAP segmentation on DTAP 
messages that are too long to be sent in a single OTA packet. 
Assist will be provided by the Line Card to minimize the OTA 
processor impact (TBD) . 

25 23) The OTA processor shall perform segmentation of short messages 
for transmission over the air in the 8 bit D-Channel. 

24) The OTA processor shall provide ARQ on all control messages 
transmitted to and received from the Radio Line Card. Three header 

30 bits have been reserved for this purpose. 

25) The OTA processor shall provide Uplink Power Control. 

26) The OTA processor shall always ensure that a time slot is 
35 allocated for 911 calls. 

27) The OTA processor shall always ensure that two time slots are 
allocated for Fast Control Traffic or 911 calls. 
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28) The OTA processor shall maintain a time slot utilization table 
for use by the Time Slot Allocation Algorithm. 

29) The OTA processor must use the Channel Utilization Header bits 
5 to report the utilization of the BS . 

30) The OTA processor shall indicate all the time slots available 
for seizure by transmitting General Polls in those time slots. 

10 31) The OTA processor shall support time slot acquisition for MSs 
requesting a time slot unless there are no time slots available. 

32) The OTA processor shall use the ^Next Slot' bits in the header 
to inform the MS which time slot to respond on. The value of the 

15 'Next Slot' pointer is controlled by the OTA processor. 

33) The OTA processor shall support Time Slot Interchange, and all 
signaling required to support intra BSC and inter BSC Handover. 

20 34) The OTA processor shall page MSs by sending Specific Polls. 
The scheduling of these pages is performed by the OTA processor. 

35) The OTA processor must maintain a TDMA frame counter for future 
use by the A5 encryption algorithm. 

36) The OTA processor must provide a mechanism with which to ensure 
that the TDMA frame counters in each communicating MS are 
synchronized to the BS . 

30 37) The OTA processor must maintain a table of candidate BSs for 
transmission over the air. 

I Interface Support 

The OTA processor must fully support the I Interface to allow 
35 the following: 

• The trcunsfer of Radio Line Card originated/terminated messages 
to and from the Line Card 

• The transfer of OTA processor originated/terminated messages 
to and from the Line Card 
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o The transfer of code from the Line Card for the BS OTA . 

Q Interface Support 

The OTA processor must fully support the transfer of control 
5 information across the O Interface. Each downlink packet will 
provide the following information in the header: 
o Origination of the packet 
o Packet type 
o Power control bit 
10 o Time slot symmetry bits 
o D- Channel Usage 

o Virtual slot mode enable /disabled 
o Channel Utilization Information 
o Next slot pointer 
15 o ARQ bits 

o Check field 

Each uplink packet will provide the following information in the 
header . 

o Origination of the packet 
20 o Packet type 

o Power control bit 

o Time slot symmetry bits 

o D- Channel Usage 

o ARQ bits 
25 o Check field 

Diagnostics Port Interface Support 

The OTA processor shall support an interface to provide the 
following : 

3 0 o The transfer of test point output data 
o The transfer of test point input data 
o Input of debug commands 
o Output of debug messages 
o Output task activity information 



35 



Fault Handl ing 
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1) The OTA processor shall monitor its hardware interrupt sources. 
On detection of a possible failure of an interrupt source, it shall 
report the error and attempt to perform a recovery procedure. 

5 2) The OTA processor shall detect any message byte -count errors in 
any 1 interface messages. 

3) The OTA processor shall detect any frame check word errors (FCW) 
errors in any O interface messages. 

10 

4) The OTA processor shall detect the following message content 
problems : 

• Invalid message type 

• Invalid message type for state 
15 • Invalid message field 

It shall discard the message and report the error. 

Functional Software Components 

20 Transceiver (TRX) Router 

The TRX Router and the OAM+P Manager form the TRX Manager. The 

TRX Router is primarily responsible for routing control traffic to 

and from each TRX Unit, configuring the TRX Units and managing the 

administrative state of each TRX Unit . 
25 For release ODl only one TRX Unit will be supported, but the 

flexibility of the TRX Router will enable the support an additional 

TRX Unit in future releases. 

Control Traffic Routing and CID Assignment 

30 This is responsible for routing control traffic to and from the 

appropriate TRX Unit and assigning Correlative IDs to each MS. The 
TRX Unit selection is based on the PID. The TRX Router must 
maintain a record of active calls on each of the TRX Units in order 
to determine the target TRX Unit . 

35 To acquire a timeslot a MS responds to a General Poll with a 

General Response, containing its PID. Once the TRX Unit receives 
the General Response it extracts the PID and enters it into a 
table. Each table location has an associated CID which will always 
be fixed to that particular entry. This ensures that each PID 
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entry will have a unique CID assigned to it . Once a call is 
released the PID is removed from the table, freeing up the CID for 
a future MS. This table contains the PIDs and their corresponding 
CIDs for all active calls. This table will be known as the Table 
S of Active Calls. It must be updated every time a timeslot is 
seized or released, so should be driven by the OTA state machine. 
So the table will only be updated by the TRX Units, and not by the 
TRX Router. At this point there is no interaction between the TRX 
Units and the TRX Router. 
10 Until a timeslot is assigned to a particular MS, the TRX Router 

will communicate with both TRX Units. This will occur during a 
Mobile Terminated Call, where pages will be sent out on both Radio 
Paths . However for the ODl release only a single TRX Unit will 
exist . 

15 When an outbound control traffic request is received by the TRX 

Router it must first extract the PID and search the Table of Active 
Calls for a match. If there is no match the message will be routed 
to both TRX Units (In future releases where more than one TRX Unit 
is supported) . A match will indicate the target TRX Unit to the 

20 TRX router and the message is routed accordingly. 

In this example a PID entry is found in the TRXl memory block, 
hence indicating on which TRX Unit the call is active on. The 
control traffic is routed to TRX Unit 1. This check occurs for 
each downlink control message. 

25 

Configuration Management 

This section describes the operation of the configuration 
management function . 

3 0 Measurement Reporting 

The TRX Router is required to provide OTA performance 
measurements to OAM which are used to provide a picture of the 
network operation. OAM is responsible for specifying the 
measurement reporting period, and the measurement types to report. 

35 

Reporting Mechanism 

A request for OAM will specify which measurement types to 
report, which triggers the TRX Router to initialize the 
corresponding measurement variables. The OAM will maintain a local 
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counter and request the measurement report from the TRX Router at 
the end of the reporting period. Upon receipt of this request the 
TRX Router must then format the result, report this to 0AM and then 
re- initialize the measurement variables. 
5 The TRX Router is responsible for initializing and reporting 

performance measurements for both TRX Units. Once the request is 
received from GAM each of the performance variables must be 
initialized. In the case of a cumulative counter (CC) variable 
should be set to zero, for a snapshot indicator (SI) two values 

10 must be initialized, namely the running total and the number of 
samples. The Gauge variables will be set to a value upon 
initialization and will only be updated if the value is modified, 
these are used mainly for configuration information. 

All Performance variables are continually updated by each of 

15 the TRX Units as each performance event occurs. But because they 
are continually updated the values are only valid if they are 
initialized at the beginning of each reporting period. This will 
only occur for the "enabled" performance measurements. 

20 Measurement Types 

This section describes the types of measurements reported by 
the TRX Router , They are displayed in the form of a table . Three 
collection methods are defined, namely Cumulative Counter (CC) , 
Gauge, and an arithmetic mean value referred to as the Snapshot 

25 Indicator (SI). 



Measurement Type 


Collection 
Method 


Description 


Successful Slot 
Acquisitions Per Cell 


CC 


The number of successful 
Time slot acquisitions in 
a cell 


Successful Slot 
Acquisitions Per Cause 


CC 


The number of successful 
Time Slot acquisitions 
per cell, on a per call 
basis {i.e. MO/MT call, 
registration, handover, 
SMS or SB Management 


Successful Bearer 
Channel Assignments 
per Cell 


CC 


The number of successful 
bearer channel 
assignments in a cell 


Unsuccessful Bearer 
Channel Assignments 
per Cell per Cause 


CC 


The number of 
unsuccessful bearer 
channel assignments in a 
cell, per cause 
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Measurement Type 


Collection 
Method 


Description 




Successful Time Slot 
Interchanges 




slot interchanges in a 
cell 




Unsuccessful Time Slot 
Interchanges 


CC 


Number of unsuccessful 
time slot interchanges in 
a cell 


5 


Available Time Slots 
per Cell 


GAUGE 


Numbe r of operati ona 1 
time slots in a cell 




Mean Number of busy 
Time Slots 




X ne X X U Altilc L. X lllcdll u J. 

the number of busy time 
slots in a cell 


10 


Maximum Number of Busy 
Time Slots per Cell 


GAUGE 


Tne nignest vaxue ror cne 
number of time slots used 
simultaneously 




Length of time All 

Time Slots were 
Allocated per Cell 


CC 


The accumulative time 
when all time slots were 
busy 


15 


Mean Time Slot Busy 
Time per Cell 


SI 


The arithmetic mean of 
the busy time for time 
slots in a cell 




Successful Link 
Recoveries per Cell 


CC 


The number of successful 
radio link recoveries per 
cell 




Lost Radio Links per 
Cell 


CC 


The number of lost radio 
links that could not be 
recovered from per cell 


20 


Relative Time Uplink 
Power Control at 
Maximum per Cell 


CC 


The time that uplink 
power control is set to 
maximum level for busy 
timeslots in a cell 




Mean Idle Time Slot 
Interference per TRX 


SI 


The mean level of 
background interference 
on idle time slots in a 
cell, per Transceiver 


25 


Administrative State 


BS Performance 
Manaaement 


Measurement s 



3 0 The State Management function is responsible for managing the 

Administrative states of the TRX Units and the TRX Router itself. 

The Administrative states of the TRX Router and the TRX Units 
are controlled by the BSC OAM and are never changed by the BS. The 
Administrative state is used to control the use of the units under 
35 control of the OAM, such as TRX Units and TRX Manager (i.e. OAM&P 
Manager and TRX Router) . The Administrative state has no influence 
on the Operational state of the unit . All Administrative state 
requests from OAM to either TRX Units are processed by the Router. 
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Administrative 
State 


TRX 
Manager 


TRX Unit 


OTA Timeslot 


LOCKED 


Not 
Possible 


Cannot be used 
for traffic. 


Cannot be used for 
traffic. (Current) 


UNLOCKED 


Not 
Possible 


Can be used for 
traffic . 


Can be used for 
traffic. (Current) 



5 

Administrative States 

The requests from OAM will specify the OTA Timeslot Number 
and/or TRX Unit (s) to be Locked/Unlocked. Each request is 

10 processed by the TRX Manager, which will in turn send a request to 
the appropriate TRX. Unit. It is not possible to change the 
Administrative state of the TRX Router, but the state of both TRX 
Units can be changed with a single OAM request. The unit hierarchy 
is as follows: on Administrative request to the TRX Manager will 

15 change the Administrative state of both the TRX Units, whereas an 
Administrative request to a particular TRX Unit will be routed by 
the TRX Manager, and will only affect the specified TRX Unit) . 

Interfaces 

20 The TRX Router interfaces to both TRX Units, the I Interface 

Manager and the OAM&P Manager. The TRX Router shares a common 
memory store with both TRX Units for Performance Measurement 
information. 

The TRX Manager is responsible for the routing of control 
25 traffic and Administrative state requests to either TRX Unit. The 
TRX Manager must likewise receive control traffic from either TRX 
Unit and send this on to the I Interface manager. All Alarm 
reports received from the TRX Units are sent to the OAM&P Manager 
by the TRX Router . 

30 The OAM&P Manager will request Performance measurements and 

Administrative state transitions from the TRX Router. In turn the 
TRX Router will transmit any Performance measurements and any Alarm 
reports to the OAM&P Manager. The TRX Router is responsible for 
the initialization and collection of all Performance Measurements 

35 requested by the OAM&P Manager. These measurements are stored in 
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an area of memory shared with both TRX Units, shown in the diagram 
as Performance Variable Store. 

The only information transferred between the I Interface 
Manager and the TRX Manager shall be control traffic requests, 
which are in turn routed to the appropriate TRX Unit depending on 
the PID. 



System Memory 

The TRX Router 
10 Variable Store must 
mately 16 variables 



will reside in local 
reside in OTA local RAM 
stored here . 



RAM. The Performance 
there will be approxi- 



Rates 

Due to the interrupt timing constraints the TRX Router should 
15 route traffic as quickly as possible. For this reason the only 
processing that should be done on the control traffic, shall be the 
search of the "Table of Active Calls". For the ODl release this 
search is not necessary because there will only be a single TRX 
Unit, but this search algorithm should be implemented for future 
20 releases. 

All OAM&P requests are serviced as low priority background 
tasks . 

Accuracy 

25 The Performance Measurements must be calculated and reported 

with as much accuracy as possible to be of use by the OMC . This 
will not be an issue with the cumulative counter Performance 
measurements, but for the SI type measurements an accurate mean 
value must be calculated. This will be achieved by maintaining a 

30 running total and a sample counter. The division between the 
running total and the sample counter will yield the gauge result. 

All Performance Variables will reside in 16 bit memory 
locations which will allow a maximum value of 131,072. If this 
value is exceeded then the variable will become invalid and should 

3 5 not be reported. This error can only be detected by the TRX Unit 
that is responsible for updating the Performance Variables. 
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TRX Unit 

The TRX Unit will be resident on the BS OTA Processor. This 
set of modules is responsible for organizing and maintaining the 
signaling links between the BS OTA and the receiver/transmitter 
5 which communicates with each MS OTA. It must accept and respond 
appropriately to information arriving in the form of MS Control 
Traffic (i.e., 0_NOTE) , I Interface Manager signals, Radio Card 
Power Control data and OAM&P Manager directives. Both I Interface 
Manager and OAMScP requests will be sent through the TRX Router 

10 before arriving at the TRX Unit. 

Version ODl will use a 16 channel' "Virtual Slot" OTA link. In 
a Virtual Slot link, the analysis and response preparation for an 
MS message arriving in the nth slot will occur between the 
completion of the receive interrupt processing for the nth slot and 

15 the transmit interrupt processing for the n+lst slot. Figure 7 
illustrates the temporal relationship between the TRX Unit 
processing and several other events and processes which support the 
Virtual Slot OTA Link. When a 32 channel design is implemented, 
the amount of processing required to analyze and respond to MS 

20 0_NOTE messages will be doubled. This will force the system to 
process two sets of input data within the 990usec interrupt window. 

The following sections describe the form and function of the 
processes to be implemented within the TRX Unit. Unless otherwise 
stated, the designs described below apply to the 16 channel design 

25 to be implemented in version ODl . 

OTA Protocol State Machine 

The TRX Unit will be designed using automata theory. The 
triggers for each transition will be messages originating from any 
30 one of four entities: 

1. I Interface Manager (via the TRX Router) 

2. OAM&P Manager (via the TRX Router) 

3. MS OTA (via 0__NOTEs placed in OTA local memory) 

4. TRX Unit Timer Management Function. 

35 The BS OTA will track the activities of up to 16 state machines 

simultaneously (one for each MS and/or network link to the BS) . 
Each of these 16 State Machines could be executing any of the 
procedures named in shown in the BS performance measurement table 
of the I Interface Manager section. 
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In a generic state machine model for example, the program 
begins in State A. If 0_NOTE "X" arrives, the machine remains in 
State A. 0_NOTE "Y" triggers a transition to State B. A signal 
from the TRX manager makes State C become active. An OAM&P request 
5 invokes a transition to State D and finally the expiration of a 
Timer internal to the TRX controller triggers a transition to State 
E. The output for each state is variable* 

Description of Processing Entities 

10 Forward Error Correction 

The TRX Unit will provide Forward Error Correction (FEC) for 
all 0_Notes traffic. MS originated 0__Notes placed in OTA local 
memory by the TDM will evaluated for bit level correctness and when 
errors are detected, the FEC algorithm will attempt to reconstruct 

15 the data in error. If a TBD number of errors occur in a single 
message, the ARQ module will be signaled to N'ack the 0__Note . If 
either no errors occur or a limited number occur and the data is 
reconstructible , the 0_Note will be accepted. 

2 0 Automatic Repeat Request (ARQ) 

The TRX Unit will provide a stop-and-wait ARQ algorithm. This 
mechanism will always be applied to 0_Notes messages but may be 
dynamically activated and deactivated for other types of traffic 
(e.g., bearer traffic). When activated, it will provide means of 

2 5 communicating (within the OTA message header) which messages 

arrived in error and which arrived accurately. 

The ARQ module will evaluate 0_NOTEs in OTA local memory. The 
ARQ module will resend the previously sent message until a timer 
expires which indicates that the BS should wait no longer for an 

3 0 acceptable response from the MS. So, a rejected (i.e., N'acked) 

0__NOTE will cause the previous OTA message to be resent until 
either it is acknowledged or a timer expires which trigger recovery 
logic. Acknowledged 0_N0TES will be sent on to the 0_N0TE analysis 
module for further processing. 

35 

0_N0TES Analysis 

The TRX Unit is serviced immediately after the TDM completes 
its Receive Interrupt processing. It begins by determining whether 
or not any MS OTA 0_NOTE was deposited into BS OTA local memory for 
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this slot. When new data is present, the TRX Unit evaluates the 
validity of the message. If the 0_NOTE is valid for the current 
state, the information elements of the message are analyzed to 
determine the appropriate actions required in response to the 
B message. These activities may include generation of an 0_NOTE 
and/or signaling the I Interface manager to generate I_NOTE data. 
When an invalid message arrives, the state remains unchanged and 
the OAMStP Manager is notified of the anomaly. 

10 Q_NOTES Development 

This process will formulate 0_NOTE messages to be sent to the 
MS. It may be invoked by either the receipt of an MS 0_NOTE which 
requires a response or a signal from the I Interface Manager (via 
the TRX Router) . Outgoing 0_NOTEs will be formatted in OTA local 

15 ■ memory and be accessible to the TDM for transport to the Radio DPR. 

OAM&P Support /TRX Alarm Manager 

The TRX Unit will maintain several OAM&P performance 
measurement variables. This data will be accessible by the TRX 
20 Router to read and initialize. 

Each member of the TRX Unit will also initiate OTA "alarms" to 
alert the OAM&P Manager when errors occur. Alarm data will include 
type, severity and cause information (see OAM&P Alarm Appendix) . 
Each Alarm will invoke the TRX Alarm Manager which will format the 
25 alarm packet and route it to the OAM&P Manager. 

Time slot Manager 

The Time Slot Manager is responsible for assigning and managing 

the O interface resource, by interworking with the O Interface 
30 Manager, This section presents a high level definition of the 

processes to be implemented in the Time Slot Manager. 

For the first release we are assuming that there is sufficient 

backhaul bandwidth to support all 16 OTA channels. This may not 

be true for all BSs in future releases, as fractional Tls could be 
35 used more efficiently in rural areas where the full 16 channels are 

not required. 
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Description 

For the ODl release the BS will support a single 16 time slot 
radio path. Of these 16 time slots one must be reserved for 911 
calls and one for fast control traffic. The reservation of these 
5 time slots is handled by the Reserved Time Slot Algorithm. The 
allocation of the remaining time slots is managed by the Time Slot 
Allocation Algorithm. Together these algorithms form the Time Slot 
Manager ., 

10 Time Slot Allocation Algorithm 

The Time Slot Allocation Algorithm is responsible for assigning 
O Interface resource in the most efficient way, and for relaying 
the channel utilization information and "Next Slot" pointer to the 
O Interface Manager for transmission in the BS packet header. This 

15 algorithm will work in conjunction with the Reserved Time Slot 
Algorithm to ensure efficient and appropriate allocation of 
resources . 

The Timeslot Allocation Algorithm will consist of three 
procedures : 

20 1. Initialization -- When the BS OTA is initialized, the Time Slot 
Map (Table 5) and Channel Utilization (CU) bits (in Table 4) 
must be unitized to the "Empty" state (reference [4]), and the 
lookup table setup as shown in Table 3- 

2. Time Slot Allocation - The OTA State machine will request a 
25 timeslot and depending on the CU bits an empty time slot will 

be selected and reserved. The CU bits will then be updated. 

3 . Time Slot Release - Again the OTA State Machine will request 
a timeslot release from the Time Slot Allocation Algorithm. 
The corresponding bit in the utilization table is then cleared 

3 0 and the CU bits updated. 

In order to track the status of each of the 16 timeslots there will 
initially be 45 x 16 bit locations reserved in memory. Of these 
locations, there are 16 reserved for the CU look-up table (Table 
3) , 25 for a cyclic channel utilization table (Table 5) and one 

35 each for the current CU value (CU Bits) , "Next Slot" pointer. 

channel utilization counter and Sub-Rate Utilization Map (Table 4) . 
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Table 3 : CU Lookup Table 
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Table 4 : Channel Utilization Parameters 
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Table 5 : Time Slot Map 



The first byte of Table 4 contains the value of the Next Slot 

20 Pointer. This value is reevaluated during each receive ISR whose 
associated OTA link is using fast control traffic. The value 
represents the number of time slots which are to occur before the 
next OTA communication with the MS. In the example shown, the Next 
Slot Pointer value is set to 10. This value will be transferred 

25 to the OTA Control Traffic Header and signals the MS to transmit 
its next message in the slot occurring 12.5 usee (i.e., 
1.25usec*10) after the beginning of the current slot. (Note: a 
value of "0" indicate that the next communication opportunity will 
occur in exactly one frame time) . In addition, this parameter 

30 causes the corresponding bit in the "Present Frame "/"Present Frame 
+1" field (in Table 5) to be set high. If the link is currently 
engaged in slot 0, a value of 10 in the Next Slot Pointer will 
cause the Present Frame bit 10 to be set. 

The next two bytes in Table 4 are the channel utilization 

35 counter and the current Channel Utilization (CU) values. The CU 
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counter indicates the number of timeslots reserved for the next 
TDMA frame. 

The current Channel Utilization (CU) bits value is derived from 
the CU Lookup Table. Each time the 
5 OTA State Machine requests or clears a time slot, a CU counter is 
incremented/decremented. In order to derive the CU bits, the CU 
counter is added to the base address of the lookup table. The 
resulting address contains the value for each of the CU bits. 

The Sub-Rate Utilization File contains a map of which slots are 
10 currently assigned to calls using sub-frame maps. Sub-frame 
mapping will not be supported in ODl and its completed design is 
TBD. 

The actual timeslots in use and reserved are stored in Table 
5 which contains "Present Frame" to "Present Frame + 24" fields. 

15 For the first release only the two lowest location will be used, 
but with the introduction of sub-rate slot allocation in a future 
release the ability to reserve a timeslot 25 TDMA frames into the 
future must be possible. 

The CU Lookup Table example indicates that there are 6 time 

20 slots currently being used and 7 time slots reserved for the next 
TDMA frame, and that the corresponding CU bits are set to 1 1 0. 

Initialization . Upon initialization. Table 5 is cleared. In 
Table 2, the three least significant bits of the "CU Bits" memory 
location are set to 1, to indicate "empty", and the CU counter is 

25 reset to 0. The 3 Isbs of each of the CU Lookup Table entry (Table 
3) are initialized. This table will be configurable. 

Time Slot Allocation . The MS will monitor the CU bits in the 
BS packet headers, and from their state make a decision as to 
whether or not to attempt a call. If the CU bits indicate that 

3 0 there are time slots available for the service required by the MS 
then the MS will initiate a time slot seizure by responding to BS 
signaling messages. 

In the slot acquisition case, each time the BS OTA prepares a 
GP packet, it must search for a free time slot and communicate the 

35 slot's relative (temporal) position to the MS. This search will 
include all timeslots from the next timeslot to the corresponding 
timeslot of the next TDMA frame. Once a free time slot is found, 
it is then reserved by marking that bit location with a 1. The 
relative position of this time slot is calculated, placed in the 



3NSDOCID: <WO 9713353A1_I. > 



wo 97/13353 PCT/US96/15190 

290 

Next Slot field of Table 4 and reported to the MS is the "Next 
Slot" field of the BS Tx Packet (reference [1] ) . The same search 
and report process occurs during all fast control traffic. 

During paging and other non-fast control traffic situations, 
5 the slot map is established based on the service requested and 
remains static until the OTA link is terminated. 

Wherever possible, the time slots should be allocated 
consecutively to ensure that bandwidth is optimized for future 
implementation of time slot aggregation. 

10 Time Slot Release . Time slot release is controlled by the OTA 

state machine. Once released, the frame allocation maps must be 
updated by clearing the bit location corresponding with the time 
slot being released. The CU Counter is then decremented, and from 
this a new CU value is derived. 

15 Reserved Time Slot Algorithm 

When resources are scarce (CU Value < 4?) , the BS OTA must 
ensure that one time slot is reserved exclusively for 911 calls and 
one time slot is reserved for fast control traffic in each TDMA 
frame. These time slots are dynamically assigned (i.e., the time 

20 slots reserved will be the last available free timeslots) so will 
not necessarily be the same for consecutive TDMA frames. 

The MS can determine the time slots available by reading the 
CU bits in the BS transmit packet header. These CU bits can be 
evaluated by the MS before slot acquisition is attempted. Table 

25 6 shows the definition of the three CU bits. 



BS 
"CU" 
state 


Channel 
Utili- 
zation 


Number of Free Timeslots 


0 


000 


All Channels Utilized 


1 


OOl 


One Channel Available, class control in effect 


2 


010 


Two Channels Available, class control in effect 


3 


Oil 


Three Channels Available, class control in effect 


4 


100 


Nearly Full, class access is xinrestricted 


5 


101 


Moderately Full, class access is unrestricted 


6 


110 


Partially Full, class access is unrestricted 


7 


111 


All Slots Available, class access is unrestricted 



Table 6: Channel Utilization Bits 
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Sub-Rate Time Slot Allocation 

A future requirement is to support bearer transmission at low 
rates, by assigning time slots every 40ms or more up to a maximum 
of 500ms. This will require the BS OTA to reserve timeslots up to 
5 500ms in advance, hence this requirement is reflected in the 25 

entry CU table. 

This feature will be required for low transmission rates for 
data or DTX on speech, but it not a requirement for the first 
release . 

Times lot AgareQation 

Timeslot aggregation is where more than one timeslot per TDMA 
frame can be assigned to a single MS for bearer traffic. This is 
not a requirement for ODl software but will be a future enhancement 
15 to the system, allowing bearer data rates beyond 9.6kbps. This 
should be bourn in mind whilst developing the software. Similarly 
a sub-rate data transmission can occur by allocating less than one 
timeslot per TDMA frame. 

2 0 Power Control Algorithm 

Link quality is optimized by ensuring that the MS is 
transmitting at its predefined optimal RF power level. The BS H/W 
must measure the BER and RSSI of the received traffic and report 
the values to the BS OTA processor so it may compare them with the 

25 threshold values. If either fall outside of ^ the threshold range 

then the MS is told to adjust its RF transmit power level by means 
of a single header bit in steps of 3dB. The Power Control 
Algorithm has the effect of improving spectral efficiency and to 
a lesser extent conserving the battery life of the MS. 

30 The Radio Card will signal (communication mechanism TBD) the 

TRX Unit when an MS Power change is indicated by the RF 
measurements. The TRX Unit will then set bits in the BS Header to 
request an increase or decrease in MS TX power. 

3 5 Timer Management 

All timers for the TRX Unit and I Interface Manager will be 
designed as decrementing counters and all will be decremented 
during TRX Unit processing. Each timer will be set to its maximum 
value and decremented each time the receive interrupt ISR is 
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executed. Table 7 lists the Timers identified in reference [l] and 
indicates the TRX Unit's responsibilities to each. 



Timer 


Decrement 


Monitor 


Reset 


BSOl-BS ONOTE Waiting for Message 


X 


X 


X 


BS02 - Slot Acquisition Waiting for MS 
DENOTE Response 


X 


X 


X 


BS03 - Slot Recovery Waiting for 
Specific Poll 


X 


X 


X 


BS04 - Special Operation and Mobile 
Call termination Waiting for Specific 
Poll Timer 


X 


X 


X 


BS05 - Slot Recovery During Traffic 
Timer 


X 


X 


X 


BS06 - Handover Attempt Timer 


X 






BS07 - Periodic Registration Timer 


NOT IMPLEMENTE 


D 


BS08 - Loss of Message from the BSC 
Timer 


X 






BS09 - Waiting for Authenticate 
Response Timer 


X 


X 


X 


BSIO - Page Pending PID Table Entry 
Timer 


NOT IMPLEMENTE 


D 



Table 7: TRX Unit Timer Management 



25 Interfaces 

TRX Unit Internal Interfaces 

The constituents within the TRX Unit will interface with each 
other by passing variables as inputs to subroutines. For the sake 
of clarity, the Timer Management module is portrayed as interfacing 

3 0 with the rest of the processes as though they were a single 

element. In actuality. Timer Management can interface with each 
module independently, depending on the timer event in progress. 
The thick unanchored arrows represent data being pass to/from 
external entities 

35 

TRX Unit External Interfaces 

The TRX Unit will interface with other processes in the BS 
through shared memory areas. Designing shared memory areas which 
contain flags and other pertinent data is preferable to a more 

4 0 formal message based interface because it reduces the timing 
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overhead required to transfer information between the TRX Unit and 
other processing entities. 

The TRX Unit and TRX Manager will share a memory area which 
will contain OAM&P parameters, NOTE requests, and Radio Power Level 
5 data. The TRX Unit will "get" and "put" data to this area as 
required. The TRX Router will be responsible for responding to 
requests from entities wishing to access this data. 

The TRX Unit will have access to incoming and outgoing 0_NOTE 
in BS OTA local memory. 0_NOTE data is moved between OTA local 
10 memory and Radio DPR by the TDM. 

Memory Requirements 

The following table lists the RAM memory requirements for each 
of the processes within the TRX Unit. These estimates are based 
15 on the eventual requirement for a 32 slot system. 



Process 


OTA Local RAM 


O NOTES Processing 


14 .5 


I Interface Signaler 


256 Bytes 


OAM&P Support 


256 Bytes 


ARQ 


12 8 Bytes 


Powe r Con t r o 1 


Bytes256 


Time Slot Management 


144 Bytes 


Timer Management 


80 Bytes 


Total 


approx 16K 



TRX Unit Memory Requirements 



In total, the TRX Unit will require approximately 16K of local 
memory for data storage. 
' 30 The RAM estimate for the O NOTEs processing assumes that the 

TRX Unit must be prepared to buffer entire DTAP messages for 
segmented transmission to the MS OTA. These estimates were 
obtained using the following equations : 

35 Memory = (Maximum DTAP Size + Maximum SMS Size)* 32 Slots * 2 + 
Size of Incoming 0_NOTE * 32 Slots + 256 Bytes for management 
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overhead = (260 Bytes -t- 176)* 32 * 2 + (21 * 32) + 256 = Bytes = 
approx K 



Rates 

5 The processing rate requirements will be driven by the OTA link 

response time requirements. In the 16 channel Virtual Slot 
configuration, the TRX Unit must analyze incoming 0_NOTE, perform 
support tasks (e.g., OAM&P data updates) and prepare (including 
Time Slot Management, ARQ and Power Control tasks) an 0_NOTE 
10 response message for transmission on the OTA link in less than 990 
usee. 

When a 32 slot/dual radio design is implemented, the receive 
ISR processing for each slot will be cut in half (i.e., 445 usee). 

15 OTDerations, Administration and Maintenance (OA&M) 

Operations, Administration and Maintenance (OA&M) provides an 
extensive set of functions for configuring and monitoring the 
system. The following list shows the functions provided by the 
OA&M: 

20 o Software Download Management 

o Configuration Management 

o Fault Management 

o Test Management 

o Performance Management 
25 o State Management 

Description 

This section describes requirements for the BS OTA OA&M. 
Software Download Management must be able to handle code download 

3 0 between the Line Card and the OTA, and maintain information on code 
object for the OTA. Configuration Management must be able to 
provide an OTA internal database, allow read/write access of the 
OTA internal database, initialize and configure the OTA, and allow 
recent configuration changes. Fault Management must be able to 

3 5 detect faults, report the faults, and in certain cases isolate and 
attempt recovery from detected faults . Test Management must be 
able to perform all the solicited tests and report the results. 
Performance Management must be able to support the gathering of 
statistical data to measure the performance of the system. State 
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Management must be able to support the administrative state 
changes . 



Software Download Management 
5 Software Download Management will perform the following 

functions : 

• initialization request 

• configuration info request 

• software loading 

10 • software activation 

Software download will be required off-line and the BS OTA must 
return to bootstrap in order to download new software. When a 
software upgrade is required, the Line Card sends the reset request 
to the OTA in order to force the OTA into boot ROM. After the OTA 

IS drops to boot ROM to prepare for receiving the new software object, 
the OTA starts its software initialization processing. At this 
time, the Load Management task will configure the Dual Port RAM in 
non-operational mode (non-prioritized queue) . A download can only 
be done after an OTA has requested initialization to the Line Card. 

20 

Initialization Request 

Upon a reset or a boot-up, the OTA will run in ROM mode . 
During boot up, the Power On Self Test (POST) task runs a self test 
and places the results in battery backup RAM. The results can be 

25 retrieved at any time. After the Power On Self Test has been 
completed, the OTA will periodically transmit an initialization 
request message to the Line Card until a response message is 
received. The result of the Power On Self Test (POST) will be 
contained in the initialization request message. When the OTA 

30 receives an initialization request response message, it will 
continue with initialization, which will include waiting for a 
configuration request and a download from the Line Card. 

Configuration Request 
35 For the software download, the OTA (while running from boot 

ROMs) receives the configuration request message from the Line Card 
via Dual Port Ram. It then returns the current OTA SW/FW/HW 
configuration information to the Line Card. The list of OTA 
SW/FW/HW configuration information is stored in flash memory. This 
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list is read and updated by the Load Management process whenever 
there is a new object load. Object information includes the object 
version number, object file ID, equipment ID, equipment type, 
equipment version number, equipment location, etc. When the Line 
5 Card receives the configuration response (current OTA configuration 
list) from the OTA, the Line Card determines whether OTA code 
object must download to the OTA. 

Software Loading 

10 OTA software can be downloaded to the OTA thru Dual Port RAM 

or serial port. If the software is downloaded through Dual Port 
RAM (i.e., network), the message formats used for the download will 
be defined in the I-interface specification (IFS-00001). 

After Line Card has determined this OTA software version is 

15 out-of-date, the Line Card forces the OTA to take a new load. A 
load must be segmented according to the dual port RAM size 
allocated. As each Load Data block comes from the Line Card, the 
OTA stores it into flash memory and acknowledges receipt of the 
"Load Data Block" message with a "Load Data Response" message. 

20 Upon receipt of the acknowledgment from the OTA, the Line Card 
sends the next segmented data block. 

Sof t ware Act i vat ion 

After the necessary OTA load object has been successfully 

25 received (or if a software version in the pTA flash memory was 
acceptable) , the OTA waits for a "Activate SW" message to start 
executing RAM code. When the OTA receives the "Activate SW" 
message, the Dual Port RAM will be configured in an operational 
mode (prioritized queues) and control will be passed to RAM startup 

3 0 code. 

Configuration Management 

The OTA Configuration Management is a subsystem of the OTA 
OA&M, The primary goals of the Configuration Management are to 
35 distribute configuration information to the OTA software tasks . 
The CM is responsible for the following major operations: 
o initialization 
^ internal database management 
o reconfiguration 
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Initial izat ion 

This procedure takes the TRX Manager and TRX units from non- 
operational to operational status. When the set parameters request 
message is received, the CM will distribute the configuration 
5 information to the TRX Manager. The TRX initialization can only 
be performed following successful completion of the TRX Manager 
initialization. The successful initialization of a TRX provides 
16 operational timeslots. The TRX initialization procedure is 
repeated for each TRX in the BS . 

10 

Internal Database Management 

This procedure must store, retrieve and update configuration 
data for the OTA. The configuration data will be maintained in an 
internal database. The CM will provide functions to slccbss 
15 parameters values in the database. 



UNIT 


Attributes 


TRXMU 


BSC IDENTITY 




. BS IDENTITY 




Location Area Code 




Mobi le Country Code 




Mobile Network Code 




Facility 




System type 




Service provider 




BS TX Power maximum 




MS TX Power maximum 




RX Mode 




TX Mode 




BS type 




Surrounding BS information 




Surrounding BS HO information 


TRXU 


Radio channel ID 
PN Code 
Maximum bearer bandwidth 
Minimum bearer bandwidth 



20 

Reconf iqurat ion 

OTA configuration parameters can be remotely modified at any 
time and are applicable to the TRX Manager and the TRX units. Some 
25 parameter modification require that the unit is first 
administratively 'locked' (as the parameter modification can affect 
on-going calls) . 
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Fault Detection 

The OTA will monitor, filter and route alarm report and alarm 
clear conditions when detected. Fault detection is accomplished 
by either the application software detecting the faults or as a 
5 result of a requested diagnostic test. In both cases, the 
detection of a fault is reported to the Line Card, which will route 
it to the BSC. 

All faults are categorized in groups defined in the following 
types : 

10 o Communication Failure Alarms 

o Quality of Service Failure Alarms 

o Processing Failure Alarms 

o Equipment Failure Alarms 

o Environment Failure Alarms 
15 Alarm conditions are assigned different severity levels. The 

OTA supports six severity levels as shown in ascending order: 

o Failure ceased 

o Critical failure 

o Major failure 
2 0 o Minor failure 

o Warning failure 

o Indeterminate failure 

All detected faults indicate the condition that causes the 

alarm. The OTA supports the following failure causes: 
25 o DPRAMiDual Port RAM interface failure (e.g., buffer overflow) 

o GPS Lost: Loss of GPS signal reception 

o Restart: OTA card processor has suffered a SW restart 
o Reset: OTA card processor has suffered a SW reset 
o Battery Not Charging: DC back-up battery is not charging 
30 correctly 

o Battery Power Lost 
o DC Power 

o GPS Receiver: GPS equipment has failed 
o Master Clock Lost:20Mhz master clock has failed 
35 o Antenna VSWR:VSWR at the antenna has reached critical value 
o HW Failure :OTA card has suffered a HW failure 
o High Temp:BS has reached an unacceptably high temperature 
o Radio Interface Lost : Communication failure on radio interface 
o Critical BER:Air interface BER has reached critical level 
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• Unused Radio : Failure suspected as radio equipment is not being 
used 

• LO Lock 

• Critical TX Power: Radio equipment HW failure 

5 • TX Power :TX power has dropped below critical level 

Fault Recovery 

The OTA supports a fault recovery mechanism which enables it 
to recover from faults during its normal operation. These faults 
10 may downgrade the performance of the OTA if no recovery action is 
in place. The recovery actions the OTA takes will relieve critical 
or major failure within the OTA. The exact fault recovery actions 
are TBD . 

15 Test Management 

The Test Management is one of the OA&M tasks. The Line Card 
initiates one of the predefined tests by sending a test request 
message. All tests are either directly performed by the Test 
Manager or are performed by dedicated tests tasks within the OTA 

20 (i.e. POST), The following types of test will be supported by the 

Test Manager task: 

• Diagnostic Tests 

• TS Loopback Test 

All of these tests can only be performed after the 
25 administrative state of the unit has been locked. Since the OTA 
will not support self-locking for these tests, the Line Card must 
send the administrative state (Unlock to Lock) change request to 
the OTA for the requested unit. 

The BS OTA diagnostic tests can be performed by boot -code 
3 0 during the system initialization (POST) or anytime it is requested. 

The results of the self test will be stored in battery backup RAM 
so that they can be retrieved at any time. If the self test fails, 
a resulting failure message is generated. The test results can be 
read by the Test Manager task upon request from the Line Card. 
35 A subset of POST hardware test can be performed after system 

startup. The diagnostic test report is sent from OTA to Line Card 
on completion of a diagnostic test, indicating whether the test was 
successfully carried out, and also the results of the test. An 
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alarm will be sent when a test fails and a previous test passed, 
or when a test passes and a previous test failed. 

The TS loopback test can be triggered by a message request from 
the Line Card at any time. The TS loopback test verifies the 
5 integrity of the bearer channel path between the Line Card to OTA 
in both directions. A radio loop test via the transceiver is used 
to test most of the equipment needed to provide service of one 
traffic channel. A channel must be locked before performing a 1- 
ooptest. The only functionality of the BS OTA for the TS loopback 

10 test is open/close loop support. 

The close loop request message is sent from Line Card to OTA 
to request that a loop-back connection is made for a timeslot. The 
BS OTA OA&M will forward this request to the TRX unit, which will 
route the message to a specific TS or all TS according to the unit 

15 id in the message. The close loop response message is sent from 
OTA card to the Line Card in response to a 'close loop request' 
message, indicating whether the loop has been successfully closed. 
The open loop request message is sent from the Line Card to the OTA 
card to request that a previously closed loop is opened for a 

20 timeslot. The open loop response message is sent from OTA card 

to Line Card in response to a *Open loop request' message, and 
indicates whether the loop has been successfully opened , 

Performance Management 

25 Performance Management functions include maintaining 

measurements and collection of statistics for hardware and software 
entities. The purpose for maintaining statistics is to collect 
data on the perfoirmance of the BS OTA subsystem. 

Some measurements can be initiated from the Line Card and 

30 others are constantly collected on an ongoing basis. Each 
measurement will be recorded and stored for further analysis. The 
Line Card will be able to manipulate the time between collections 
of all or individual statistics. Multiple measurement types can 
be initiated by the Line Card. 

35 When the OA&M receives the "Start Measurement Request" message 

with the measurement type and reporting period (5, 15, 30, or 60 
minutes) from the Line Card, it will forward this request to the 
TRX Router. There are three different collection methods; 
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Cumulative Counter (CO, Gauge, and an arithmetic mean value 
referred to as the Snapshot Indicator (SI) . 

Performance statistics are kept in tables by the TRX units. 
The TRX Router collects measurements from each table, formats them 
5 based on the measurement type and reports them to the OAScM at the 
end of each reporting period. All TRX router reports must be 
reported to the Line Card before the next interval . The OTA OA&M 
will continue collecting measurements from the TRX Router and 
reporting them to the Line Card until a stop measurement request 
10 is received . 

State Management 

The BS OTA will support Lock, Unlock, Shut -Down administrative 
state change requests from the Line Card. The OTA will change its 
15 state when a new administrative state is requested by the Line 
Card. The OTA will start with the Administrative state = 'Locked' . 
After initialization completion of the TRX Manager and TRX units, 
the OTA must be unlocked by the Line Card. 

When the TRX unit is unlocked, 16 channels are automatically 
20 unlocked. When the TRX unit is locked, 16 channels are 
automatically locked. A channel must be locked before performing 
a loopback test . 

Upon receipt of the administrative state request from the Line 
Card, the OA&M will route this message to the TRX Manager, which 
25 will send it to the appropriate TRX unit{s). 

If the OTA receives an Unlock command, the OTA is in service. 
If the OTA receives a Shut-Down state change command, the OTA will 
wait for all on-going calls to be completed. 

While the unit is in the Locked administrative state, the Line 
30 Card can initiate the following activities (of the OTA) : (1) 
perform any pre-defined test, (2) reconfiguration, or (3) software 
upgrade . 

Interfaces 

3 5 The OTA OA&M interfaces to both TRX Router, the I Interface 

Manager, Post and the Debug Port Manager. 

The OA&M Manager is responsible for the following functions: 
(1) configuration of the TRX Manager and TRX units 
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(2) collecting the alarms from the TRX Router, Debug Port 
Manager, I Interface manager, and the Post tasks and filtering them 
before reporting them to the Line Card. 

(3) administrative state request to the TRX Router. The TRX 
5 Router will route it to the appropriate TRX unit (s) for state 

changes . 

(4) performance measurement request to the TRX Router. 

(5) diagnostic test request to POST and loopback test request 
to TRX Router. 

10 (6) serial code download from dualport manager. 

Debug Port Manager 

The Debug Port Manager provides an interface to the debug port. 
The debug port is not described in detail here, it will however 
15 support the following functions. 

Description 

The Debug Port Manager is comprised of two main functions: 
logging useful debug data information and accepting command 

2 0 requests. The Debug Port Manager will be capable of logging state 
machine information, event/error information, O Interface messages, 
and I Interface Messages. Loggers will copy information to a 
common information buffer that will be output to the debug port, 
as time permits, by the Debug Port Manager. The O Interface 

25 Manager will log the state machine information and the O Interface 
messages. The I Interface Manager will log the I Interface 
Messages. The events and errors will be logged by either the O 
Interface or I Interface Manager. The Debug Command Handler is the 
part of the Debug Port Manager that will handle requests for 

30 information via input from the debug port. This information will 
be sent out the debug port . 

Interfaces 

The O Interface Manager will write the state machine 
35 information, the event/error information and the Traffic buffer 
information for the current slot into the common buffer area that 
can be grabbed by the Debug Port Manager. The I Interface Manager 
will write the NOTES buffer for a slot into the common buffer area 
that can be grabbed by the Debug Port Manager, The Debug Command 
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Handler interfaces with the debug port to obtain input requests and 
provide output results. It also interfaces with the Loggers to 
logging on and off for the various logging functionality. It must 
also interface with the OAM&P Manager by initiating a request for 
5 a download via the debug port . 

State Machine Logger 

The State Machine Logger provides access to the OTA state 
machines. The current state of each time slot can be reported via 
10 the debug port. 

Description 

The purpose of the State Machine Logger is to allow the 
developer /Integra tor access to the state information for each time 

15 slot while the OTA processor is running. The information as to 
what state a particular time slot is in could then be displayed on 
a PC connected to the debug port. This state information will be 
very helpful in debugging and determining the operational status 
of the OTA Processor and the Handsets connected to this Base 

20 Station. 

The State Machine Logger will be used by the O Interface 
Manager and will store the state information in real time, as to 
what the state of the current time slot is, in the common 
information buffer, if State Machine Logging is enabled. This 
25 information will then be output over the debug port by the Debug 
Port Manager from the common information buffer. 

Interfaces 

The State Machine Logger when called by the O Interface Manager 
30 will write the state machine information for the current slot, into 
the common information buffer that can be accessed by the Debug 
Port Manager- The data that will be stored by the State Machine 
Logger will include time slot number, unit base station number, and 
current state. This state information should be logged upon entry 
35 into the 0 Interface Manager interrupt. 

Event /Error Logger 

Any error conditions or user defined events can be detected and 
reported via the debug port . 
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The purpose of the Event/Error Logger is to allow the 
developer/integrator access to the events and errors for each time 
slot while the OTA processor is running. The information as to 
what event or error a particular time slot has experienced could 
5 then be displayed on a PC connected to the debug port. This 

event/error information will be very helpful in debugging and 
determining the operational status of the OTA Processor and the 
Handsets connected to this Base Station. 

The Event /Error Logger will be used by either the O or I 
10 Interface Manager and will store the event or error information in 
real time as to what event just occurred for the current time slot 
in the common information buffer, if Event/Error Logging is 
enabled. This information will then be output over the debug port 
by the Debug Port Manager from the common information buffer. 

15 

Interfaces 

The Event /Error Logger when called by the O or I Interface 
Manager will write the event/error information for the current slot 
into the common information buffer that can be accessed by the 

20 Debug Port Manager. The data that will be stored by the 
Event/Error Logger will include time slot number, unit base station 
number, and event /error indication. The event /error indicator 
should be only two bytes of information in order to keep the 
transfers through the debug port to a minimum. This allows 6 553 6 

25 different indicators for errors and 65536 different indicators for 
events. 

Interface Logger 

The 0 Interface Logger provides visibility to the OTA Dual -Port 
30 RAM. This will support data capture for all TDMA time slots. 

Description 

The purpose of the O Interface Logger is to allow the 
developer/integrator visibility to the O Interface Traffic buffer 
3 5 information for each time slot while the OTA processor is running. 

The Traffic buffer of information received from the Handset as well 
as the Traffic buffer of information to be sent to the Handset 
could be displayed on a PC connected to the debug port . This state 
information will be very helpful in debugging and determining the 
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operational status of the OTA Processor and the Handsets connected 
to this Base Station. 

The O Interface Logger will be used by the O Interface Manager 
and will store the Receive and Sent Traffic Buffers in real time 
for the current time slot in the common information buffer, if O 
Interface Logging is enabled. This information will then be output 
over the debug port by the Debug Port Manager from the common 
information buffer . 



10 Interfaces 

The O Interface Logger when called by the O Interface Manager 
will write the Traffic buffers for the current slot into a data 
area that can be accessed by the Debug Port Manager. The data that 
will be stored by the O Interface Logger will include time slot 

15 number, unit base station number, Receive Traffic buffer, and 
Transmit traffic Buffer. The Receive buffer information and the 
Transmit buffer information should be logged just before exit from 
the O Interface Manager interrupt . 

2 0 Interface Logger 

The I Interface Logger provides access to the NOTES Dual Port 
RAM. This will support data capture for the NOTES associated with 
all TDMA time slots. 

25 DescriiDtion 

The purpose of the I Interface Logger is to allow the 

developer/integrator visibility to the I Interface NOTES buffer 

information for each time slot while the OTA processor is running. 

The NOTES buffers received from the Line Card Processor as well as 

3 0 the NOTES buffers sent to the Line Card Processor could be 

displayed on a PC connected to the debug port. This state informa- 
tion will be very helpful in debugging and determining the 
operational status of the OTA Processor and the Line Card Processor 
in this Base Station. 
3 5 The I Interface Logger will be used by the I Interface Manager 

to write the Received and Sent NOTES Buffers in real time for a 
time slot into the common information buffer that can be accessed 
by the Debug Port Manager, if I Interface Logging is enabled. This 
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information will then be output over the debug port by the Debug 
Port Manager from the common information buffer. 

Interfaces 

5 The I Interface Logger when called by the I Interface Manager 

will write the NOTES buffer for a slot into the common information 
buffer that can be accessed by the Debug Port Manager. The data 
that will be stored by the I Interface Logger will include time 
slot number, unit base station number. Receive or Transmit NOTES 
10 Buffer. The Receive NOTES buffer should be logged upon receipt of 

an interrupt that a NOTE has been received. The Transmit NOTES 
buffer should be logged just before setting the interrupt request 
for the Line Card Processor to know that there is a NOTE request 
for it to receive. 

15 

Debug Command Handler 

Access to the inner workings of the Base Station will be via 
the debug port. This handler will be part of the Debug Port 
Manager and is responsible for decoding and initiating the commands 
20 sent by the user. The list of commands supported from a functional 
standpoint are as follows: 

o Enable/Disable the State Machine Logger, 
o Enable/Disable the Event /Error Logger. 
o Enable/Disable the 0 Interface Logger. 
25 o Enable/Disable the I Interface Logger, 
o Enable/Disable all Loggers. 

o Filter Logger output by time slot number, 
o Request status information of OAM&P . 
o Initiating download for OAM&P processing. 
30 o Access RTOS command line interface to obtain information like 

Displaying memory locations. Changing memory locations. See 

what tasks are running. Queue status, etc. 

Description 

3 5 The Debug Command Handler handles all commands that come in 

from the debug port. These commands provide the. functionality of 
enabling and disabling the various logging functions, as well as 
supporting OAM&P requests for download, etc. and supporting the 
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RTOS functions of displaying and modifying memory locations and 
more . 

The commands for enabling and disabling the logging functions 
will merely enable or disable that form of logging. There will be 
5 one command that turns on and off all logging functions as well. 
The logging status will be returned to the debug port after 
processing the command request . 

The command that initiates the downloading, via the debug port 
will actually initiate an OAM&P function to take control of the 
10 debug port in order to perform the download. Once the download is 
completed, then control of the debug port will return to this Debug 
Command Handler. Other OAM&P status information can be requested 
as well and the requests will be sent on to the OAM&P Manager and 
the status results returned and displayed by the Debug Port 
15 Manager. 

The requests to display and modify memory locations in the OTA 
Processor will include the ability to access DPR locations as well. 
Other RTOS information will be requested and displayed based on the 
functionality of the Command Line Interface of the chosen RTOS. 

20 This debug port is only designed to be used for system 

debugging, and therefore is limited in scope. The loggers are 
intended to provide the main visibility into system operation on 
the Base Station for debugging purposes. They may also be used in 
troubleshooting. The majority of the operational analysis will be 

25 done using the OAM&P functionality. 

Interfaces 

The Debug Command Handler interfaces with the debug port to 
obtain input requests and process those requests. It also 
3 0 interfaces with the Loggers to enable and disable logging for the 
various logging functionality. It must also interface with the 
OAM&P Manager by accepting requests. It also interfaces with the 
RTOS to provide the visibility available by the Command Line 
Interface . 

35 

Traffic Data Manager (TDAI) 

In previous BS versions the IDM was called the Controller and 
resided on a separate processor card, but it is now incorporated 
into the OTA processor card. The TDM is responsible for managing 
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the radio fink, data movement, global bus arbitration and 
supervision . 

Description 

5 The main function of the TDM is to move Control Traffic between 

the radio dual port and OTA buffers and move the Voice and Data 
Traffic between the radio and line card dual port using DMA 
transfers. In the process of copying these data buffers, the TDM 
must control access to the global bus. During the DMA process, no 

10 interrupts can occur in the OTA until the DMA transfer is com- 
pleted. If the radio link is not up then it must zero out the 
buffers. The TDM will also transfer the power control information 
from the Radio Dual Port to OTA RAM for use by the TRX Unit 

There are two different ways that the hardware can be 

15 configured to handle the time slots. One is called intra -slot and 
one is called virtual slot. There is a bit in the Traffic Header 
bytes that indicates whether the Base Station is in Intra-slot or 
Virtual slot mode. This bit is under software control. Intra-slot 
pertains to a Handset transmitting its traffic message immediately 

20 followed by the Base Station message which is in response to that 
Handset message. Virtual slot pertains to a Handset transmitting 
its traffic message for slot N and the Base Station transmitting 
its response to slot N-l Handset message. The rest of this 
description pertains to handling the virtual slot case. The intra- 

2 5 slot case will not be handled by this design, but this design will 

not preclude future enhancements toward the intra-slot case. 

The Control Traffic data is copied from the radio buffers to 
the OTA buff ers and from the OTA buffers to the radio . The 
Voice/Data Traffic is copied from the radio buffers to the line 

3 0 card dual port and from the line card dual port to the radio 

buffers. In both cases, the header information of the OTA buffers 
is always passed from/to the radio buffers to/from the OTA buffers. 

The copying of a radio buffer to and from its respective area 
will be done in two separate interrupts. One interrupt will be the 
35 receive interrupt and one interrupt will be the transmit interrupt. 

The receive interrupt handler will copy the receive data to the OTA 
RAM and the transmit interrupt handler will copy the data from the 
OTA RAM. 

The receive interrupt routine will perform the following: 
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• The receive interrupt will check which radio was indicated by 
the hardware to have the best received data (based on antenna 
diversity) and copy the data from that radio buffer into the 
appropriate OTA buffer and/or line card dual port buffer for 

5 a particular slot. 

• It will then call the 0 Interface Manager to process the 
received data and set up the data to transmit in response. The 
0 Interface Manager will have a maximum of 990us available to 
get the data ready for the transmit interrupt. This is the 

10 time available in the receive interrupt after transferring the 

receive data into the OTA . 
The transmit interrupt routine will perform the following: 

• The copying of an OTA buffer and/or a line card dual port 
buffer to the radio buffer for a particular OTA slot will be 

IS done during a transmit interrupt . 

In an intra-slot system the data has to be stored for 
transmitting at the end of processing your receive interrupt data 
because you would have to process the last data and get ready to 
send the next data for this same slot within the time between the 

20 end of the receive time and the beginning of the transmit time. 
This time is only around lOOus. 

The TDM Transmit interrupt occurs 550us after the start of the 
slot. The TDM Receive interrupt occurs 660us after the start of 
the slot. The EOS Interrupt occurs 810us after the start of the 

25 slot and is not used in this design. The O Interface Manager 
cannot have access to the OTA Buffer Ram until the TDM has 
completed the transfer of the received data. This time is ISOus 
after the occurrence of the receive interrupt. These times are 
based on the current hardware design used for the PIOLOT system. 

30 

It takes llOus to transfer the transmit data and ISOus to 
transfer the receive data. This leaves only 990us per time slot 
to do the rest of the necessary processing for that time slot. 

3 5 Interfaces 

The TDM assumes that by the time it gets in to process the 
transmit interrupt, that the O Interface Manager has already stored 
the response Traffic Message (including header bits) in the 
transmit buffer for the particular slot in the OTA Ram. The O 
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Interface Manager also assumes that before it gets its interrupt 
to process the OTA Traffic data that the TDM has finished 
transferring the data from the Radio to the OTA RAM. 

5 Performance 
Memory 

The TDM should use about 3K bytes of program memory. This 
should not be a significant use of data memory space since the 
majority of its functionality is to copy buffers from Dual Port or 
10 local RAM. 



Rates 

The processing time needed for the IDM should be about 260us. 
15 The estimated time to transfer the transmit buffer should take 
about llOus per slot. The estimated time to transfer the receive 
buffer should take about 150us per slot. These times reflect the 
fact that these transfers are done using DMA. 

20 Timing 

The TDM needs to ensure that it operates as quickly as possible 
with the buffer transfers so that the majority of the slot 
interrupt time can be used for other purposes. This is a critical 
feature of the software. 

25 

Accuracy 

The data transfers will be completely accurate assuming no 
memory failures . 

3 0 Availability/Reliability 

The IDM should always be available to transfer either the 
transmit or receive data. The TDM should be interrupt driven by 
the hardware. There can be one interrupt for transferring the 
transmit buffer and one interrupt for transferring the receive 

35 buffer. 

Error Procedures 

The following errors could occur and must be handled by the 

IDM: 
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Error : 

Description : 
Example : 
Action : 



Unable to Access DPR 

The TDM cannot access either Radio, Line Card or 
OTA RAM. 

DMA transfer fails because TDM cannot write to 
DPRAM . 

Control will be passed to the RTOS . 



10 



15 



20 



Error : 

Description : 
Example : 
Action : 



Error : 

Description ; 

Example : 
Action : 



25 



Buffer Overrun 

Previous data has not been processed before the new 
data arrives. 

Control message from the Line Card DPR arrives 
before previous data has been cleared. 
This could be accomplished by having the two 
interrupts check to see if the last interrupt was 
processed by checking an interrupt status flag. If 
this error occurs it will be reported to the OAM&P 
Manager . 
Faulty Card 

The TDM detects a faulty Radio, Line Card or OTA 
processor . 

Cannot access one of the Radio cards. 
Bus arbitration will be disabled for the faulty 
board so that the global bus can not become hung up 
by the faulty card and not allow other users to 
access the global bus. 



Design Issues 

The O Interface Manager will be called from the receive 
interrupt. This decision was made based on how the implementation 

3 0 of the PELOT has proceeded and will be further evaluated as to 
whether this is the most optimum solution. It may be decided at 
a later time that the O Interface Manager should use its own 
interrupt, the EOS interrupt. 

During the DMA transfer from or to any DPR the OTA Processor 

35 cannot receive any interrupts. This has been confirmed by Rusty 
Meeks. The DMA transfer must be completed before an interrupt can 
occur. This is not a problem with the transfers done in the TDM, 
but for the transfers made from the Line Card DPR for NOTES, this 
is a very serious issue. Per Dave Hetherington ' s memo dated 
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5/31/95 on PCS2000 DPR Issues, it is stated that the transfers for 
the radio traffic take about 3 0 us. Since the Line Card DPR NOTES 
transfers are with larger blocks of data, then it is reasonable to 
assume that those transfers will take more than 30us. It then 
5 follows that interrupts could be delayed at least as much as 3 0us 
(the Line Card DPR transfer time) . The only way to avoid this 
delay would be to have the TDM module transfer the Line Card DPR 
data as well as the radio and line card traffic data. This would 
ensure that interrupts would not be disabled for any unknown period 
10 by the DMA transfer of NOTES. 

Don't know how faulty card will be detected. 

Real Time Operating System (RTOS) 

The OTA processor will use a commercially available RTOS. The 
15 RTOS will primarily be used for task scheduling and task messaging. 

Description 

The RTOS will be the scheduler for the Base Station tasks. The 
highest priority is servicing the SCU and O Interface Manager. The 

20 lowest priority is servicing the OAM&P Manager, Diagnostics 
Manager, and the OAM&P Manager. The RTOS will be managing tasks 
that will be primarily message driven. They will receive a message 
and process the request. Some tasks will send a message on to 
another task or send a message to an external interface like dual 

25 port ram or the serial port. 

The features of an RTOS that could be used by the OTA Base 
Station Processor are task management, semaphore handling, event 
management, time management, message management, memory management, 
and peripheral resource management . 

30 

Task Management 

Task Management could provide for the scheduling of all tasks 
or just the background tasks. The scheduler could be priority 
based, time sliced, and/or preemptive. 

35 
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Semaphore Handl ing 

The Semaphore handling could aid in backplane/global bus 
accessing for handling dual port access. Ibis handling could be 
used for any conditions that could provide contention on memory 
5 resources . 

Timer Management 

Timer Management could help tasks set timers and be notified 
of their expirations asynchronously. Tuners could be added or 
10 deleted for a particular event, as well as set, reset, and halted. 

Message Management 

Messages could be created and filled in with information to be 
sent to a task. Messages could be sent to a task and received from 
15 a task. The task could be in a suspended state until it receives 
a message. It could leave that suspended state either in response 
to receiving a message or after a Certain time interval. 

Memorv Management 

20 Several areas of memory could be allocated as buffer areas. 

Each area could contain a number of buffers which could be 
allocated to a task and then released back to the buffer pool when 
no longer needed. Buffer pools could be created for various 
functions and for various tasks. 

25 

Peripheral Resource Management 

The serial port used for the debug port could be a resource 
that could be managed by the RTOS. This would allow for tasks to 
avoid conflict in their access to this resource. Refer to the 
30 Diagnostic Manager section for use of the debug serial port. 

Availabilitv/Reliabilitv 

Most commercial products will be reliable. They should be 
reliable to perform as promised, but there is always the unknown, 
3 5 untried areas that could prove very interesting. The only way to 
ensure reliability is to have previous experience with the product 
or to talk with someone who has extensive experience with the areas 
that you wish to utilize. The RTOS must be able to recover if the 
task scheduler is overloaded. We cannot tolerate thrashing. 
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Power On Self Test (POST) 

The POST will perform the following functions: 
o Cold Boot . 
o Warm Boot . 
5 o Device and Peripheral Tests, 
o RAM Initialization, 
o Watchdog Reset . 



Description 

10 'rhe POST functions provided on the Base Station OTA Processor 

consist of Cold Boot, Warm Boot, Device and Peripheral Tests, RAM 
initialization, and Watchdog Reset. All of these functions will 
be performed before initiating or after halting the normal 
operation of the OTA Processor. These functions can also be 

15 initiated by the OAM&P Manager after system start up via function 

calls . 

The POST will also copy the current version number of the 
software in the ROM to the revision register in the hardware. This 
revision register contains hardware, firmware, and software version 
2 0 numbers. See hardware document for format. 

Cold Boot 

The Cold Boot will take place on the processor upon system 
reset, after Watchdog Tuner expiration, and upon request from the 

25 OAM&P Manager. The entire OTA Processor system will be started 

with no history knowledge of the past. Upon completion of the Cold 
Boot, the system will start up the RTOS and all the associated 
tasks and interrupt handlers. It will then return the status of 
the tests to the OAM&P Manager who will then be the one to decide 

30 if this Base Station should be unlocked (available to the network) 
based on the returned status. The following steps will occur as 
part of the Cold Boot : 

<^ Set up all chip selects to allow access to all data areas 
35 described in the hardware map of this processor. 

o Initialize all R7^ data areas used by the operation of the OTA 

Processor. o Perform all device and peripheral tests to 

determine hardware viability, 
o Set up all peripheral device registers. 
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Initialize all trap vector tables. 

Initialize the interrupt handlers so that they will be ready- 
to begin receiving and processing interrupts. 

Start up the RTOS and the tasks that are to be controlled by 
it . 

Return status of self tests to OAM&P upon completion of startup 
along with the revision register contents. 



10 



15 



20 



Device and Peripheral Tests 

There will be several device and peripheral tests that will be 
performed as part of the Cold Boot. These will be the type that 
are traditionally done in a POST (Power on Self Test) to verify the 
functionality of the base hardware. They will include the 
following : 



• Watchdog timer test 



• R7^ Device test 



• ROM Device test 



• DMA test 



• Timer test 



Debug port serial test 



Set timer to a particular 
timeout and check to see 
that the timer expires 

Test reading and writing 
to various RAM locations 
with a known pattern to 
test data as well as 
address lines. 

Compare checksum in ROM 
with newly computed c- 
hecksum. 

Test reading and writing 
to various areas, in each 
DPR (Radio, OTA, Line C- 
ard) . 

Test setting a timer and 
having the timer expire. 

Test writing and reading 
from the debug serial port 
with it set up in echo 
mode . 



Warm Boot 

The Warm Boot will take place on a soft reset. Reasons for 
this soft reset, include but are not limited to, task aborted, etc. 
2 5 This Warm Boot will insure that the OTA Receive and Transmit inter- 
rupts continue to be handled regardless of the operation of the 
other tasks in the system. Upon Warm Boot the following steps will 
occur : 
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o Any task not currently running will be restarted. This means 
that only tasks which have aborted will lose their queued data. 
Since most operations have timers associated with them and they 
try a certain number of times before giving up, this should 
only affect the response time but not the response. 

o Tasks currently running will not be changed. 

o No data areas will be reinitialized, therefore, the state of 
each time slot will be maintained along with all the necessary 
information for all current calls. Current calls will be 
maintained . 

RAM Initialization 

The RAM initialization will be performed during a Cold Boot 
only. The areas to be initialized are as follows 
o All Slot state information 

o All transmit/receive buffers for all slots 

o All I Interface data structures pertaining to NOTE transfers. 

All line interface/slot information structures. 
o Configuration data, 
o Stack and heap setup. 

o General data areas initialized to zero and/or initialized from 
ROM initialization values. 

Watchdog Reset 

The Watchdog timer will be used to insure the integrity of the 
system. Upon expiration of this timer, the system will be issued 
a reset which will cause a Cold Boot and the OAM&P Manager will 
be notified. The system will normally ensure that this timer does 
not expire under normal operations. However, if the system is not 
operating as it should, then this timer will not be cleared and 
hence will cause a Watchdog system reset. The Watchdog timer will 
support the following: 

o The Watchdog timer will perform a reset (Cold Boot) upon 
expiration. 

o The Watchdog timer will, upon expiration, save registers and 
history data so that it can be looked at after the restart . 
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• The Watchdog timer will be reset periodically, to show that 
the system is functioning normally, so that it will not cause 
a system reset . 

5 Interfaces 

The POST initializes the OTA Processor Dual Port RAM during 
initialization. The POST uses the debug port on the 341 board to 
send out error indicators during Cold Boot. 
Performance 
10 Capacities 

The POST will reside in a single FLASH ROM and never be 

Rates 

The Cold Boot will be completed and status returned to the 
15 OAM&P Manager in no more than 2 seconds after initiation. 

Accuracy/ Precision 

The POST will be accurate in its determination as to whether 
or not the OTA Processor is operational. 

20 

Availability/Reliability 

The POST uses the Watchdog Tuner to help insure that the 
system is functioning. Since it performs tests before enabling 
the RTOS, tasks, and interrupt handlers, it insures that the 
25 functioning of the OTA Processor is as reliable as it can 
determine. The results are returned to the OAM&P Manager and then 
it decides whether this Base Station should be fully operational. 

PHYSICAL LAYER INTERFACE 

3 0 This section addresses the I interface in the scope of network 

layer 426 protocols (i.e. NOTES). Memory require-ment s are 
addressed with the assumption of shared memory (e.g. Dual Port 
Ram) serving as the physical interface. However, from a 
functional point of view we should not assume that the physical 

35 interface will always consist of some form of shared memory. For 
all practical purposes we can assume that there is a layer 2 
protocol even if none exists. This will facilitate porting the 
software to different hardware architectures in the future. 
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The I interface provides a framework which supports a 
standardized method of physical device interfacing. It allows a 
Layer 2 (OSI-Data Link Layer), message-based interface to the 
different physical devices supported by the O-BTS hardware. All 
5 I interface messages support connection establishment and termin- 
ation, data transmission and reception, and call control and OAM&P 
management functions. The Dual Port Ram will be used as the Data 
Link medium between the O-BTS LC and the OTA processor. 

10 I Interface Prioritized Oueing 

The system requirements specify that Handoff events have a 
distinct priority over most other events in the system. Similarly 
Call Control events have priority over OAM&P events. This 
suggests from the point of view of the application peer entities 

15 that messages sent through the interface should be tagged with 

priorities. An interface manager (i.e. layer 2) would be required 
to manage multiple prioritized queues I across the physical 
interface. In this document it is assumed that a prioritized 
queue consists of both a sending and a receiving queue. Th 

20 following are the priority levels: Priority 1 - Handoff s and 

Emergency Events , 

Priority 2 - Communication Management (DTAP Notes), 
Priority 3 - OT^ & P. 

25 Multiple Prioritized Queues The 
management of multiple prioritized queues with fixdd length 
message buffers is probably the easiest to implement and the most 
efficient from an execution standpoint. 

At least three separate prioritized queues will be 

30 implemented. An exception to this is during a Base Station 
software download from the Base Station Controller. If the Base 
Station is in the Out-Of -Service state it may be more efficient 
for the BS Line Card OMU (OAM&P -Management Unit) to commandeer 
most if not all of the shared memory for software load transfer 

35 across the I interface. 
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Queuing Algorithm Impacts 

The same queuing algorithms must be implemented on both 
sides (Line Card Processor and OTA Processor) of the I Interface. 
This means the OTA Processor and the Line Card Processor will 
5 execute a common set of functions to implement the queuing 
mechanism . 

I Interface Message Buffering 

A small message buffering algorithm per BS OTA slot to 
10 facilitate the delivery of BS to MS^ messages will be implemented. 

In particular this could be useful during handoff where the 
terminating Base Station does not yet have contact with the Mobile 
Station but has more than one message to deliver to the MS. 

When the BS OTA is sending a segmented NOTES Transport message 
15 to the MS and another message from the network arrives for the MS, 
the following queuing algorithms will be implemented: 

• One large FIFO (for each priority level) for all the OTA 
slots on the physical interface and then individual 
FIFO's per OTA slot in the OTA processor. 
20 This would simplify the interface from the Line Card 

perspective and would provide a more flexible method of access to 
the physical interface. It also removes many sizing constraints 
from the interface into the OTA processor. 

25 I Interface Memory Requirements 

The memory requirements for bearer traffic can be calculated 
as follows: 

32 Slots/BS * 2 (Xmit/Rcv Buffers) * 36 Bearer-Bytes/ Buffer 

= 2304 Bearer-Bytes/BS 
3 0 The memory requirements for the message queues are TBD. It 

has been suggested from sources in Digital Hardware Development 
that they could support Dual Port RAM sizes on the order of 3 2 
Kbytes. If so this is probably more than sufficient memory for 
a 32 slot Base Station. 

35 

APPLICATION PROGRAMMING INTERFACE (API) 

This section defines the services provided to the application 
SW by the physical layer Interface manager. Messages between the 
I -interface Manager and the Application Tasks are supported 
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through use of the API functions. All API functions are available 
to the application tasks through the API. The following services 
are supported by the API for OTA. 
1 . dpr_conf ig (map) 

2. drp_send (data_ptr , length, priority) 

3 . dpr_receive (data,_ptr, length) 

These functions can be implemented by using the real-time 
kernel function calls. The Interface manager is responsible for 
copying data from Dual port memory into locals memory. 



dpr__conf ia 

Upon power-up or reset, the OTA will run boot -code, where the 
full Dual Port RAM may be used for SW download. The OTA will 
configure the Dual Port RAM in Non- operational mode by calling the 

15 dpr-config function with a map which contains the address of non- 
prioritized queue and the buffer size. After downloading the 
code, the OTA will start executing the RAM code. When the set 
parameters request is received, the OTA will switch into 
Operational mode, where the Dual Port RAM is partitioned into 

20 prioritized queues. To configure the Dual Port RAM in an 
operational mode (prioritized queues) , the OTA should call the 
dpr_conf ig function with a map which contains multiple prioritized 
queue addresses. This function returns a 0 if the Dual Port RAM 
is configured successfully. The format is int dpr_conf ig (map) , 

25 where the map is the map of the queue addresses. 

dpr_send 

In order to send a message to the I -interface manager, the 
following steps should be followed: 
30 o Place the message data into a buffer. The data buffer 

can be allocated either statically or dynamically, 
o Call dpr_send with a pointer to the data buffer, data 

buffer length, and message priority, 
o If any buffers were allocated dynamically and are no 
35 longer needed, release them. 

The format is int dpr_send (data-ptr, length, priority) where 
data_jptr is the pointer to data buffer, length is the size of the 
data buffer, and priority is the message priority. The priority 
can have the following values: 
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0: Nonoperat ional procedures i.e., OTA initiali-sation) , 
1: Handoffs and Emergency msg, 
2 : DTAP NOTES , and 
3 : OAM&P . 

5 

dpr_receive 

In order to receive a message from the I -interface manager, 
the following steps should be followed: 

1) Allocate a message data buffer. The data buffer can be 
10 allocated either statically or dynamically. 

2) Call dpr_receive with the address of the data buffer 
address and the data buffer length. 

3) Check the return code of the dpr_receive call. 

If any buffers were allocated dynamically and are no longer 
15 needed, release them. 

The format is int dpr__receive (data_ptr , length) where data_ptr is 
the pointer to data buffer for the received message and length is 
size of the data buffer 

2 0 APPLICATION LAYER INTERFACE 

OAM&P application messages described in this section will be 
used for communication with the I -interface manager. 

Messaaef ormats 

25 To help ease implementation and avoid porting restric- tions, 

message formats, and elements are defined at even byte lengths. 
Multi-byte message elements should start on even byte boundaries. 
This is a reasonable approach because the messages only traverse 
the BS backplane and not a bandwidth sensitive serial link, 

3 0 Messages are not always fixed format and an Information 

Element coding approach is used. 

General message header 

A general message header is used in all OAM&P messages on the 
35 I -interface, that allows identification of a specific 
functionality (using a Message ID) and a specific base station 
UNIT (using a UNIT ID) . The general message header has a 2 byte 
message identifier, a 1 byte TRX number, a 1 byte time slot number 
and a 2 byte length message. 
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The TRX number distinguishes between TRX UNITs within a BS , 
The Times lot number distinguishes the times lot with a particular 
TRX. When addressing a TRX, the timeslot number is null. When 
addressing a timeslot a TRX number must be specified. The TRX 
Manager is addressed by both TRX nunber and Timeslot number being 
null. 



10 



Message Identifier Coding 

Table 11-1 shows the addressable units and coding for messages 
that are defined for the I -interface . 



Table 11-1: I -interface messages 





Unit 


Coding 


Initialisation Request 


TMU/THXU 


01 


Initialisation Response 


TMU/TRXU 


02 


Configuration Information 


TMU 


03 


Request 


TMU 


04 


Conf igurat ion Inf ormat ion 






Response 






Load Initiate Request 


TMU 


05 


Load Initial Response 


TMU 


06 


Load Data Block 


TMU 


05 


Load Data Block Response 


TMU 


06 


Load End Request 


TMU 


OS 


Load End Response 


TMU 


06 


Set Parameters Request 


TMU/TRXU 


07 


Set Parameters Response 


TMU/TRXU 


1 08 


Alarm Report 


TMU/TRXU 


09 


Alarm Response 


TMU/TRXU 


OA 


Diagnostic Test Request 


TMU 


OB 


Diagnostic Test Response 


TMU 


OC 


Diagnostic Test Request 


TMU 


OD 


Diagnostic Test Response 


TMU 


OE 


Close Loop Request 


TSU 


OF 


Close Loop Response 


TSU 


10 


Open Loop Request 


TSU 


11 


Open Loop Response 


TSU 


12 
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Start Measurement Request 
Start Measurement Response 


TMU/TRXU 
TMU/TRXU 


13 
14 


Measurement Report 
Measurement Report Response 


TMU/TRXU 
TMU/TRXU 


15 
16 


Stop Measurement Request 
Stop Measurement Response 


TMU/TRXU 
TMU/TRXU 


17 
18 


Administrative State Change 
Request 

Administrative State Change 
Response 


TMU/- 
TRXU/TSU 
TMU/- 
TRXU/TSU 


19 
lA 


Administrative State Change 
Report 

Administrative State Change 
Response 


TMU/- 
TRXU/TSU 
TMU/- 
TRXU/TSU 


IB 
IC 


Reset Request 
Reset Response 


TMU 
TMU 


ID 
IE 



Initialization Request 

This message is sent from the OTA card (from boot-code for 

2 0 TMU) to the Line card as an indication that a unit is ready for 

initialisation. He message is sent repeatedly approximately 
every 5 seconds, until 'Initialisation response' is received from 
the Line card (note that DP RAM initialisation is the final task 
of the Line card initialisation, and that the.. Line card will see 
25 the next 'Initialization request' message following this). 

For TRX Manager initialisation, the self test results which 
include a mandatory 6 byte header are included within the 
'Initialization request' message. The Line card will not 
initialize the TRX Manager in case of self test failure. 

30 

1) Self test results are present for the TRX Manager 
initialisation, and are not present for the TRX 
initialisation . 

3 5 Initialization Response 

This message including the 6 byte general header is sent from 
the Line card to the OTA card (to boot -code for TMU) , to inform 
the OTA that the 'Initialization request' has been received. 
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Configuration Information Request 

This message including the 6 byte general header is sent from 
the Line card to the OTA card (to boot -code for TMU) , requesting 
that the TRX Manager return the current base station HW 
5 configuration and SW/FW version information. 

Configuration Information Response 

This message including the 6 byte general header is sent from 
the OTA card (from boot -code for TMU) to the Line card, and is 
10 used by the TRX Manager to provide the current base station HW 
configuration and SW/FW version information. 

Load Initiate Request 

This message including the general header is sent from the 
15 Line card to the OTA card (boot code) , and informs the OTA of the 
identity of the OTA SW file to be downloaded, and the Dual Port 
RAM MAP to be used. 

Load Initiate Response 
2 0 This message with the general header is sent from the OTA card 

(boot code) to the Line card, in response to a Load Initiate 
Request message, and indicates whether the OTA card is able to 
receive the SW load (2 bytes) . 

25 Load Data Block 

This message having the general header is sent from the Line 
card to the OTA card (to boot-code) , and contains a single block 
of an OTA SW file greater then 3 bytes. 

3 0 1) This element contains a block (of between I byte and 3 0 K 
bytes) of the OTA SW file. 

Load Data Block Response 

This message including the general header is sent from the OTA 
35 card (from boot-code) to the Line card, in response to a Load Data 
Block message, and indicates whether the block of SW has been 
successfully written to FLASH RAM (2 bytes) . 



^JSDOCID: <WO 9713353A1_L> 



wo 97/13353 



PCT/US96/15190 



325 

Load End Request 

This message including the general header is sent from the 
Line card to the OTA card (boot code) , to inform the OTA card that 
the SW load is complete. 

5 

Load End Response 

This message is sent from the OTA card (boot code) to the Line 
card, in response to a Load End Request message, and indicates 
whether an OTA SW file has been successfully received. 

10 

Activate SW Request 

This message which includes the general header is sent from 
the Line card to the OTA card (boot code) , to request that the OTA 
starts running its RAM software. The Dual Port RAM NW informs the 
15 OTA of the prioritized queues to be used by the operational OTA 
software . 

Activate SW Response 

This message which includes the general header is sent from 
20 the OTA card to the Line card in response to an Activate SW 
Request message, and indicates whether the OTA software has been 
successfully started (2 bytes) . 

Set Parameters Request 
25 This message which includes the general . header is sent from 

Line card to OTA card, requesting that configuration parameters 
are set for either TRX Manager or TRX unit. 

1) present for TRX Manager unit 

2) present for TRX unit 

30 

Set Parameters Response 

This message which includes the general header is sent from 
OTA card to Line card in response to Set Parameters request 
message, and indicates the success or failure of configuration 
3 5 parameter setting for TRX Manager or TRX units (2 bytes) . 
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Alarm Report 

This message is sent from OTA card to Line card, indicating 
that either a UNIT failure has been detected, or that some notable 
event has occurred . The message includes the general header (6 
bytes) , failure type (2 bytes) , failure severity (2 bytes) , 
failure cause (2 bytes) , hardware description (optional) , software 
description (optional) , and 40 bytes of additional information. 

1) present in the case that additional information regarding a 
failure is given. 

2) present in the case that a hardware failure is reported 

3) present in the case that a software failure is reported 

Alarm Response 

This message which includes the general header is sent from 
Line card to OTA card in response to an Alarm Report message. 

Diagnostic Test Request 

This message which includes the general header is sent from 
Line card to OTA card requesting that a diagnostic test is 
performed for the OTA card. This test is a non-destructive subset 
of the Power-On Self Test (POST) . 

Diagnostic Test Response 

This message which includes the general header is sent from 
OTA card to Line card in response to a Diagnostic test request, 
indicating whether the test has been accepted. (2 bytes) . 
1) A successful 'Outcome' is only an indication that the test has 

been accepted . 

Diagnostic Test Report 

This message which includes the general header is sent from 
OTA card to Line card on completion of a diagnostic test, 
indicating whether the test was successfully carried out (2 
bytes), and also the results of the test. 

1) indicates only whether the test was completed (not if the test 
was passed successfully) . 

2) the results of the test are present if the test was completed. 
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Diagnostic Test Report Response 

This message which includes the general header is sent from 
Line card to OTA card in response to a Diagnostic report message. 

5 Close Loop Request 

This message which includes the general header is sent from 
Line card to OTA card to request that a loop-back connection is 
made for a timeslot (2 bytes) . 

10 Close Loop Response 

This message which includes the general header is sent from 
OTA card to the Line card in response to a 'Close loop request' 
message, indicating whether the loop has been successfully closed 
(2 bytes) . 

15 DA successful 'Outcome' indicates that the a closed loop has 
been made for the requested timeslot. 

Open Loop Request 

This message which includes the general header is sent from 

2 0 the Line card to the OTA card to request that a previously closed 

loop is opened for a timeslot (2 bytes) . 

Open Loop Response 

This message which includes the general header is sent from 
25 OTA card to Line card in response to a 'Open Loop Request' 
message, and indicates whether the loop has been successfully 
opened (2 bytes) . 

1) A successful 'Outcome' indicates that the loop has been re- 
opened for the timeslot. 

30 

Start Measurement Request 

This message is sent from Line card to OTA card to request 
that a number of measurement types be started. The message 
includes a general header (6 bytes) , reporting schedule (2 bytes) , 

3 5 and measurement type (2 bytes) . 

1) can be repeated to start multiple measurement types. 
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Start Measurement Response 

This message which includes the general header is sent from 
the OTA card to the Line card in response to a 'Start measurement 
request' message, and indicates whether the requested measurements 
5 have been successfully started {2 bytes) . 

1) indicates whether the requested measurements have been 
successfully started . 

Measurement' Report 
10 This message is sent from OTA card to Line card, transferring 

measurement results. The message ' includes the general header, 
measurement type (6 bytes) , and measurement result (4 bytes) . 
1 ) can be repeated to report multiple measurement types . 

15 Measurement Report response 

This message which includes the general header is sent from 
Line card to OTA card in response to a 'Measurement result report' 
message . 

2 0 Stop Measurement Request 

This message which includes the general header is sent from 
Line card to OTA card to request that a number of measurement 
types are stopped {2 bytes) . 

1) can be repeated to stop multiple measurement types. 

25 

Stop Measurement Response 

This message which includes the general header is sent from 
OTA card to Line card in response to a 'Stop measurement request' 
(2 bytes) . 

3 0 1) indicates whether measurements have been successfully stopped. 

Administrative State Change Request 

This message is sent from Line card to OTA card to change the 
administrative state of a unit. The message can be used to 
35 'Lock', 'Shut-down' or 'Unlock' a unit. 

o In the case of lock request, any calls handled by the 

unit are immediately released, 
o In the case of a shut-down request, the OTA will not 

allocate new calls and will wait 3 minutes before 
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forcing the administrative state to locked (releasing 
any remaining calls) . 
• In the case of an unlock request the unit is 

immediately allowed to handle new calls . 

5 

If a unit is administratively 'Locked' then all subordinate 
units are unable to handle calls (e.g., if TMU is 'Locked' then 
all TRXUs and all TSUs cannot handle calls) . 

The message includes a general header and the information of 
10 the administrative state (2 bytes) . 

1) the requested administrative state can be 'Locked', 'Shuting- 

down' or 'Unlocked' . 



Administrative State Change Response 

15 This message which includes the general header is sent from 

OTA card to Line card in response to a 'Administrative state 
change request' message (2 bytes) . It does not signify that the 
state change has occurred, only that the request is, allowed. 
1) indicates that the requested administrative state change 

20 cannot be performed. 

Administrative State Change Report 

This message which includes the general header is sent from 
OTA card to Line card to report that the administrative state of 
25 a unit has changed (2 bytes) . The reported .administrative state 
can be 'locked' or 'Unlocked'. 

1) the reported administrative state can be 'Locked' or 
'Unlocked' . 

3 0 Administrative State Change Report response 

This message which includes the general header is sent from 
Line card to OTA card in response to a 'Administrative state 
report ' message . 

^5 Reset Request 

This message which includes the general header is sent from 
Line card to OTA card to re- initialisation of the HW supporting 
the 'TRX Manager', 'TRX' and 'TS' units. The OTA processor 
performs a cold reset, returning to boot -code and performing 
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power-on self tests. Only OTA SW stored in flash memory remains 
after the cold reset. 

Reset Response 

5 This message which includes the general header is sent from 

OTA card to Line card in response to a 'reset' message, and is 
sent immediately before the reset is performed. 

Element Coding 

10 The following is the list of message elements and related 

identifier information. 

Additional information 

The additional information element includes a 1 byte element 
15 identifier and a 39 byte message regarding the failure or alarm. 

Administrative state 

The administrative state information element includes a 1 byte 
element identifier and 1 byte element defining the administrative 

2 0 state. The states are encoded as 01 for locked, 02 for unlocked, 

and 03 for shutting down. 

Diagnostic test results 

The diagnostic test results information element includes a 1 
25 byte identifier and the diagnostic test results. 

Dual Port RAM MAP 

The dual port RAM map information element includes a l byte 
identifier, a 2 byte element indicating the number of queues, and 

3 0 for each queue a 2 byte start write pointer, a 2 byte start read 

pointer, a 2 byte pointer to the beginning of the queue on the 
line card and a 4 byte queue length. 

Failure cause 

3 5 The failure cause information element includes a 1 byte 

element identifier and a 1 byte failure cause. The failure cause 
is generally one of the following: TI SYNC LOST, DPRAM, GPS LOST, 
WARM RESET, COLD RESET, AC POWER LOST, BATTERY NOT CHARGING, 
BATTERY POWER LOST, MASTER CLOCK LOST, ANTENNA VSWR, HW FAILURE, 
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ASSAULT, HIGH TEMP, RADIO INTERFACE LOST, CRITICAL BER, UNUSED 
RADIO, LO LOCK, CRITICAL TX POWER, and SW FAILURE. 

Failure severity 

5 The failure severity information element includes a 1 byte 

element identifier and a 1 byte failure severity message. The 
failure severity message is defined as follows: Failure ceased 00, 
Critical failure 01, Major failure 02, Minor failure 03, Warning 
failure 04, and Indeterminate failure 05. 

10 

Failure tvpe 

The failure type information element includes a 1 byte 
element identifier and a 1 byte failure type. The failure types 
are defined as follows: Communications failure 00, Quality of 
15 service failure 01, Processing failure 02, Equipment failure 03, 
and Environment failure 04. 

File Block 

The file block information element includes a 1 byte element 
20 identifier, a 2 byte block length indicating the number of OTA 
software file in the block, and the block of the software file. 

HW configuration 

The hardware configuration information element includes a 1 
25 byte element identifier, a 2 byte length of the hardware 
information, and the requHardwareware information for the OTA and 
each radio to which the element relates. 

HW Description 

3 0 The hardware description information element includes a 1 byte 

element identifier, the ID of the equipment to which the message 
relates, the type of equipment, the version of the equipment and 
the equipment location. 

35 Measurement results 

The meaurement results information element includes a 1 byte 
element identifier and a 3 byte element giving the information 
results . 
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Measurement type 

The measurement type information element includes a i byte 
element identifier and a 1 byte element of the measurement type. 
The measurement types include: Successful initial slot 
5 acquisitions 1, Successful slot acquisitions per cause 2, 
Successful B channel assignments 3, Unsuccessful B channel 
assignments per cause 4, Successful timeslot inter-changes per 
cause 5, Unsuccessful timeslot inter-changes 6, Available slots? 
7, Mean number of busy slots 8, Maximum number of busy slots 9, 
10 Time all slots allocated 10, Mean slot busy time 11, Successful 
radio link recoveries 12, Lost radio links 13, Relative time UL 
power control at maximum 14, and Mean idle slot interference 15. 

Outcome 

^5 The outcome information element includes a 1 byte element 

identifier and a 1 byte outcome of the requested action. The 
outcomes are as follows: Success 0, 1 unknown unit, 2 unknown 
message, 3 incorrect message length, 4 illegal message, 10 file 
already exits, 11 insufficient memory, 12 incorrect block size, 

20 13 illegal parameter value, 14 unable to perform operation, 15 too 

many measurements. Messages 1-4 and 10-15 all denote a failure 
of the requested action. 

Reporting schedule 
25 The reporting schedule information element includes a 1 byte 

element identifier and a 1 byte element representing the reporting 
schedule. The following are the reporting schedules: each 5 
minutes 1, each 15 minutes 2, each 3 0 minutes 3, and each 4 0 
minutes 4 . 

30 

Selftest results 

The self test result information element includes a 1 byte 
element identifier and a 1 byte element of the self test result. 

3 5 SW conf iaurat ion 

The software configuration information element ioncludes a 1 
byte element identifier, a 2 byte length element, and a 
description of the OTA software and firmware. 
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SW Description 

The software description information element includes a 1 byte 
element identifier, information identifier the software file, and 
the software version. 

5 

TMU parameters 

The following table describes the TMU parameters. 



Element Identifier 


1 byte 


BSC IDENTITY. Identifies a BSC uniquely. 


2 bytes 


BS IDENTITY Identifies a BS uniquely within 
a Location Area. 


4 bytes 


LOCATION AREA CODE, Grouping of BS/Cells 
that is used for the location updating 
procedure . 


2 bytes 


MOBILE COUNTRY CODE. Uniquely identifies 
the country in which a PLAIN is located. 


2 bytes 


MOBILE NETWORK CODE. Uniquely identifies a 
PLAIN within a country. 


1 byte 


FACILITY. Identifies the BS service and 
access restrictions . 


4 bytes 


SYSTEM TYPE. Identifies the code set of the 
supporting infrastructure as DCS 1900 . 


1 byte 


BS LOCATION. Location information for 
configuration of the GPS receiver. 


tbd 


BS TX POWER MAXIMUM- Identifies the maximum 
power at which the BS can transmit. 
(Coding) 


tbd 


MS TX POWER MAXIMUM. Identifies the 
maximum tbd power at which the MS can 
transmit to the BS (i.e., in the cell), 
(coding) 


tbd 


RX MODE. Indicates the mode in which the 

BS receivers should operate . 

Interference limited 0 
Noise limited 1 


1 byte 
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TX MODE. Indicates the mode in which the BS 
transmitters should operate. 

Linear 0 

Non linear 1 


1 byte 


5 


BS TYPE. Indicates the BS type, and is used 
as an input to the MS HO algorithm, and to 
indicate the capability of the BS 
transmitters . 


1 byte 


10 


SURROUNDINGS BS INFORMATION, Information 
on up to 11 surrounding Bss (zero filled if 
less than 11 surrounding Bss) 

Base Frequency {coded as Radio Channel 

ID, section 5.3.19), 


(11*4 ) =44 
bytes 

1 byte 


15 


Base PN code (coded as PN code, 

section 5.3.19) 


1 byte 


20 


Base type (coded as BS type, 

section 5.3.18) . 

Base Placement Not concentric 0 

Concentric 1 


1 byte 
1 byte 


25 


SURROUNDING BS HO INFORMATION. The precise 
use of this element is not yet known, but 
it will provide something like: 

Priority information for Hos to each 
surrounding BS (for weighting of Hos) 


tbd 


30 


HO margin information for HO to each 
surrounding BS (to prevent repetitive 
HOs) . 





35 
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TRXU parameters 



The following table defines the TRXU parameters. 



5 


Element Identifier 


1 byte 




KAJJiU y^riAliritsLt XUc«rJ 1 ±r liiK . iCtentltieS trie 

0.625 MHz radio channel within the PCS 
spectrum to be used by the TRX . 


1 byte 


10 


1850 00 0 MHz 0 0 hf^v 
1850.625 01 

1989.375 DF 
1990.000 EO 




15 


PN CODE- Identifies the Pseudo- random Noise 
code to be used for the direct sequence 
spread spectrum modulation, 
(coding is to be defined) 


1 byte 


20 


MAXIMUM BEARER BANDWIDTH. The maximum 
number of TDMA timeslots that can be 
assigned to a bearer channel. 

Note: must be "1" at this time. 


1 byte 


25 


MINIMUM BEARER BANDWIDTH. The maximum 
number of TDMA timeslots that can be 
assigned to a bearer channel. 

Note: must be "1" at this time. 


1 byte 




SPARE To give element even number of bytes 


1 byte 



30 FUNCTIONAL SCENARIOS 

This section describes the context in which the OAM&P messages 
are used. 

Administrative state procedures are shown in a number of 
scenarios {e.g., to 'Lock' a unit before performing a test), and 
35 are used to reduce the impact of OAM&P operations on-going 
services. It is the responsibility of either the operator or the 
BSC to control Administrative states, and the Base Station will 
not check these before performing service impacting operations. 
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Initialization 

This procedure takes a UNIT from non operational to 
operational status, and is applicable to ' TRX Manager' and 'TRX' 
UNITS . 

5 

TRX Manager Initialization 

This procedure takes the TMU from non -operational to 
operational status. The TMU initialisation must be performed 
before any other I-interface procedure is possible. Figure 6:TRX 
10 Manager unit initialisation procedure illustrates this procedure. 

TRX Initialization 

This procedure takes the TRXU from non -operational to 
operational status. The TRXU initialisation can only be performed 
15 following successful completion of the TMU initialisation. The 
successful initialisation of a TRXU provides 16 operational 
timeslots. The TRX unit initial-isation procedure is repeated for 
each TRX unit in the BS . 

2 0 Reconfiguration 

This procedure modifies the configuration of units which are 
already operational, and is applicable to 'TRX Manager' and 'TRX' 
units. Some parameter modifications require that the unit is 
first administratively 'locked' (as the parameter modification can 

25 affect on-going calls) . 

TRX Manager reconfiguration 

The reconfiguration procedure can be performed at any time 
following the initialisation of the TRX Manager unit. 

30 

TRX reconf igura t ion 
The reconfiguration procedure can be performed at any time 
following the initialisation of the TRX unit. 

3 5 gW ungrade 

This procedure is used for upgrade of the OTA SW and is the 
same as the OTA reset procedure. 
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Alarm reporting 
This procedure is used to report UNIT failures or events. 
The Alarm Manager Task is a component of OTA OAM&P management. 
The individual alarms are not specific to the Alarm Manager 
5 Task, but are delivered to the Alarm Manager by other tasks 

within the OTA. After processing, alarms are passed to the 
Line Card OAM&P. Alarms are not processed until the 
initialization is completed . 

10 Testing 

This procedure is used for management of BS testing (either 
'BS diagnostic test' or ' TS looptest'). The diagnostic test must 
be addressed to the TMU when it is operational, and will result 
in a non-destructive test of the OTA card. The TS looptest can 

15 be adressed either to a specific timeslot or to all timeslots; of 
a specific TRX, but can only be performed when the TRX is 
operational. The TS looptest verifies the integrity of the bearer 
channel path between Line Card to OTA in both directions. 



2 0 Operadonal Measurements 

This procedure is used for management of BS Performance 
measurements. The Line Card requests measurements with the 
measurement type and reporting period to the OTA. During this 
test, the OTA is responsible for reporting measurements to the 
25 Line Card within the allowed reporting interval T time period. The 
OTA will continue collecting mesurements until a stop measurement 
request is received from the Line Card . 

Administration 

3 0 This procedure is used for control of the UNIT Administrative 

state. The OTA processes Lock, Unlock, and Shut -Down 

Administrative State change request messages from the Line Card. 
All state change messages contain a Unit Identifier. 

35 Reset 

The reset procedure triggers the re-initialisation of theHW 
supporting the 'TRX Manager' and "TRX' units. The OTA processor 
performs a cold reset, returning to boot -code and performing 
power-on self tests. Only OTA SW stored in flash memory remains 
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after the cold reset. Re - initialisation of ' TRX Manager' and 

'TRX' units will be performed by the Line-card following the OTA 
reset . 



5 Alternative Embodiments 

While preferred embodiments are disclosed herein, many 
variations are possible which remain within the spirit and scope 
of the invention. Such variations would become clear to one of 
ordinary skill in the art after inspection of the specification, 

.0 drawings and claims herein. The invention therefore is not to be 
restricted except by the scope of the appended claims. 
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CLAIMS 

What is claimed is: 

1. A system for transferring information within a 
5 communication system, comprising 

a base station comprising a transceiver and a backhaul 
interface element, said transceiver capable of communicating with 
a plurality of user stations, one in each time slot of a time 
frame , 

10 a base station controller connected to said backhaul 

interface element, and 

an interface between said transceiver and said backhaul 
interface element, whereby information sent from said user 
stations is stored by said transceiver and accessed by said 

15 backhaul interface element for communication to said base station 
controller, and information sent from said base station controller 
is stored by said backhaul interface element and accessed by said 
transceiver for communication to designated ones of said user 
stations . 

20 

2 . The system of claim 1 wherein said interface comprises 
a dual -port random access memory. 

3. The system of claim 2 further comprising a plurality of 
25 prioritized queues, each of said prioritized queues located in a 
designated portion of said dual -port random access memory. 

4 . The system of claim 3 wherein a signaling message 
received by said transceiver is selectively placed in one of said 
30 prioritized queues. 

5. The system of claim 3 wherein said prioritized queues 
are three in number. 

35 6. The system of claim 1 wherein said backhaul interface 

element comprises a line card processor. 
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7. A base station interface comprising 

a transceiver capable of communicating using a time division 
multiple access technique with a plurality of user stations, one 
in each time slot of a time frame, said transceiver comprising a 
5 transceiver processor, 

a backhaul interface element, said backhaul interface element 
comprising a backhaul interface processor, and 

a dual -port RAM connected to said transceiver and said 
backhaul interface element, said dual-port RAM comprising a first 
10 memory portion for storage of first information by said 
transceiver from user stations and retrieval os said first 
information by said backhaul interface element, and a second 
memory portion for storage of second information by said backhaul 
interface element and retrieval of said second information by said 
15 transceiver. 

8. The base station interface of claim 7 wherein said dual- 
port RAM comprises a plurality of queues, each associated with a 
designated priority. 

20 

9. The base station interface of claim 8 wherein signaling 
messages are stored in said queues according to a relative 
priority of each signaling message. 

25 10. The base station interface of claim 7 further comprising 

a base station controller connected to said backhaul interface 
element . 

11. The base station of claim 7 wherein said base station 
30 communicates with said user stations using spread spectrum 

communication . 

12. A system for transporting messages in a mobile 
communication system, comprising 

35 a plurality of user stations, 

a plurality of base stations each having a backhaul interface 
element and each having a transceiver for carrying out time 
division multiple access communication with said user stations. 
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a base station controller connected to said backhaul 
interface element in each of said plurality of base stations, 

an internal interface within each base station, connecting 
said backhaul interface element to said transceiver, 
5 a first set of messages for communicating signaling and user 

information between said user stations and said base stations, 

a second set of messages for communicating said signaling and 
user information across said internal interface, and 

a third set of messages for communicating said signaling and 
10 user information from said base stations to said base station 
controller . 



13 . The system of claim 12 wherein messages from said first 
set of messages are transmitted in information packets including 
15 a header field, a bearer field, and a byte-serial field. 

14 . The system of claim 13 wherein a message from said first 
set of messages is sent either within said bearer field in a 
single one of said information packets, or within said byte-serial 
20 field over a plurality of said information packets. 

15 . The system of claim 12 wherein messages from said second 
set of messages are stored in a shared memory accessible by said 
backhaul interface element and said transceiver. 

25 

16. The system of claim 15 wherein a first message from said 
second set of messages is derived from a second message from said 
first set of messages or said third set of messages. 



30 17. The system of claim 12 wherein messages from said third 

set of messages are transmitted in data frames comprising an 
opening flag, an address field, a control field, and an 
information field. 

35 18. The system of claim 15 wherein a message from said third 

set of messages is sent within said information field in a single 
one of said data frames . 
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19. The system of claim 12 wherein messages from said second 
set of messages is sent in the same format as messages from said 
third set of messages. 

20. The system of claim 12 wherein said base stations 
communicate with said user stations using direct sequence spread 
spectrum communication . 

21 . The system of claim 12 wherein said base station 
controller is connected to a telephone network. 



22. A communication system comprising 

a plurality of communication channels, each of said channels 
defined by a time slot from among a plurality of time slots and 
15 a code from among a plurality of codes, 

a base station having a transceiver and a line card 
processor, 

a plurality of user stations, each capable of communicating 
with said base station over one of said communication channels, 
20 an interface internal to said base station, said interface 

comprising a shared memory between said transceiver and said line 
card processor, 

a base station controller connected to said line card 
processor, whereby information is transported between said base 
25 station controller and said user stations by way of said line card 
processor, said internal interface and said transceiver. 

23. The communication system of claim 22 further comprising 
a plurality of base stations connected to said base station 

30 controller . 

24 . The communication system of claim 22 wherein said shared 
memory comprises a dual -port RAM. 

3 5 25 - A method for transferring information within a time 

division multiple access communication system, comprising the 
steps of 
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defining a continuous series of time frames, 

defining a plurality of time slots in each time frame, 
whereby one of a plurality of user stations may communicate with 
a base station in each one of said time slots, 
5 receiving a signaling message to be communicated between a 

base station and one of a plurality of user stations, and 

transmitting in a designated time slot, using a spread 
spectrum technique, an information packet between said one user 
station and said base station, said information packet having a 
10 header flag set to a first value to indicate that said signaling 
message is contained in a first field, and set to a second value 
to indicate that a segment of said signaling message is contained 
in a second field smaller than said first field. 

15 26. The method of claim 25 further comprising the step of, 

where said header flag was set to said second value, transmitting 
in said designated time slot and using a spread spectrum technique 
additional information packets in siobsequent time frames, each of 
said additional information packets containing a different segment 

20 of said signaling message, until the entirety of said signaling 
message has been transmitted between said base station and said 
one user station. 

27. The method of claim 25 wherein said first field is used 
25 for sending bearer data when not used for sending signaling 

information. 

28. The method of claim 25 further comprising the step of 
storing said signaling message in a queue in said base station. 

30 

29. A communication system comprising a base station, said 
base station comprising a base station transceiver; 

a plurality of user stations comprising a user station 
transceiver for communication with said base station over a base 
35 station to user station interface, said base station and said user 
station comprising circuitry for establishing a time frame 
comprising a plurality of time slots; 
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a base station controller in communication with said base 
station through a base station to base station controller 
interface ; 

a dual access memory comprising a first input and a second 
input, said first input coupled to said base station to base 
staion controller interface and said second input coupled to said 
base station to user station interface, 

control traffic signals are communicated across said base 
station to user station interface, said control traffic signals 
comprising a fast traffic control mode and a slow traffic control 
mode; said fast control traffic mode comprising an exchange of 
signals across said base station to user station interface in a 
plurality of time slots within a timespan of a single time frame 
and said slow control traffic mode comprising an exchange of 
signals across said base station to user station interface a 
maximum of once per time frame and wherein said exchange of 
signals across said base station to user station interface in said 
slow control traffic mode need not occur in every successive 
timeframe . 



30 The communication system of claim 30 wherein said 
exchange of signaling messages within a specific time frame in 
said fast control traffic mode comprises a base station 
transmission comprising information directing said user station 
25 to exchange signals in said slow control traffic mode. 

31. The communication system of claim 30 wherein said base 
station transmission is responsive to a user station transmission, 
said user station transmission comprising a signaling message 

30 comprising information requesting said base station to exchange 
signals in said slow control traffic mode. 

32. The communication system of claim 29 wherein said 
control traffic signals comprise a message in said slow control 

35 traffic mode including information for setting the rate of said 
exchange of signaling messages over a number of consecutive time 
frames. 
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33. The communication system of claim 29 wherein said 
traffic control signals exchanged within a single time frame in 
said fast control traffic mode comprises a base station 
transmission comprising information for determining the quantity 
and position of time slots to be used for said exchange of 
signaling messages in said fast control mode. 

34. A communication system for supporting a low rate 
continuous signaling link, comprising 

a base station, 

a first user station wherein said first user station and said 
base station periodically exchange control traffic information 
using a periodic time frame, said periodic time frame comprising 

one or more time slots, 

said periodic exchange of control traffic information 
occurring in a single time slot within a time frame, and 

said periodic exchange of control traffic information 
occurring no more frequently than once every other time frame. 

35. The communication system of claim 34 wherein said 
exchange of control traffic information comprises a base station 
transmission comprising information for adjusting said frequency 
of said exchange of control traffic information. 

36. The communication system of claim 34 further comprising 
a second user station which periodically exchanges control 

traffic information with said base station, wherein 

said periodic exchange of control traffic information between 
said base station and said second user station occurs in the same 
time slot as said time slot used by said first user station and 
said base station, and wherein 

said periodic exchange of control traffic information between 
xid base station and said second user station occurs in a 
riodic time frame different from said periodic time frame 
rein said periodic exchange of control traffic information 
•een said base station and said first user station occurs. 
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37. The communication system of claim 34 wherein the number 
of consecutive time frames in which said periodic exchange of 
control traffic information does not occur is not greater than 
thirty-one . 

38. A communication system using a slow control traffic 
mode, comprising 

a base station, and 

a plurality of user stations, wherein 

each of said user stations exchanges signalling information 
with said base station in a single time slot within a periodic 
time frame, and wherein 

said exchange of signaling information between said base 
station and each respective user station occurs no more frequently 
15 than every other periodic time frame. 

39. The communication system of claim 38 wherein 
at least two of said user stations alternately exchange signalling 
information with said base station using the same time slot in a 
different time frame. 



10 



20 



25 



30 



35 



40. The communication system of claim 39 wherein the number 
of said user stations exceeds the number of available time slots 
within said periodic time frame. 

41. A communication system for dynamically varying the 
transmission of signalling information, comprising 

a base station, 

a user station, and 

a signaling link between said base station and said user 
station, said signaling link comprising 

a first exchange of signaling information between said base 
station and said user station in a plurality of time slots in a 
first periodic time frame, wherein 

said first exchange of signalling information comprises a 
base station transmission comprising information data for 
determining the number and position of time slots to be used in 
a second time frame for a second exchange of signalling 
information . 
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42. The communication system of claim 41 further comprising 
a second exchange of signalling information between said base 
station and said user station in a second time frame using said 
time slots determined by said information data in said base 
5 station transmission in said first time frame. 

43 . The communication system of claim 42 wherein said number 
of said time slots used for said second exchange of signaling 
information in said second time frame is greater than the number 
10 of said time slots used for said, first exchange of signalling 
information in said first time frame. 

44. A method for establishing a low rate continuous 

signaling link between a base station and a user station in a 
15 communication system, comprising the steps of 

transmitting in one or more time slots within a periodic time 
frame a first transmission from said base station to said user 
station, said transmission comprising a signaling message 
comprising both a command for said user station to acknowledge 
20 entry into said signaling link and data specifying the rate of 
exchange of signaling messages over a fixed number of time frames 
in said signaling link, 

receiving said first base station transmission at said user 
station, 

25 transmitting from said user station in one or more time slots 

within said time frame a user transmission comprising an 
acknowledgement of said command by said base station, 

receiving said user station transmission at said base 
station, and 

30 exchanging signaling messages periodically between said base 

station and said user station over the course of a plurality of 
time frames, said periodic exchange of said signaling messages 
occurring at said rate specified by said base station. 

35 45. The method of claim 44 further comprising the step of 

transmitting from said base station within a time frame during 
said signaling link a signalling message which varies said rate 
of said periodic exchange of said signaling messages in said 
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signaling link, said rate-varying signaling message comprising 
information specifying a new rate. 

46. The method of claim 44 further comprising the step of 
5 transmitting from said base station within a time frame during 

said signaling link a signaling message which varies the slot 
position used by said base station and said user station for said 
exchange of signaling messages in said signaling link, said slot- 
posit ion-varying signaling message comprising information 
10 specifying a new slot position. 

47. A method for accelerating signaling information over a 
communication interface, said interface comprising a plurality of 
control messages transmitted and received by a base station and 

15 a user station in one or more time slots within a periodic time 

frame , 

comprising the steps of 

exchanging control messages between said base station and 
said user station in one or more slot positions in a first time 
2 0 frame, 

during said exchange in said first time frame, transmitting 
from said base station a control message comprising information 
for designating a plurality of available slot positions to be used 
for a second exchange in a succeeding time frame, and 
25 exchanging control messages between said base station and 

said user station in said designated slot positions in said 
succeeding time frame . 

48. The method of claim 47, wherein 
30 quantity of said designated plurality of slot positions in 

said subsequent time frame is greater than quantity of said one 
or more slot positions in said first frame. 
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EJcmcni Identifier 


1 byte 


NUMBER OF QUEUES. Indicates uic number of pnon- 
tizcd queues in the Line card DP RAM 


I byte 


QUEUE 1 PUT PTR. The address of the pointer used for 
wnting to queue 1 of the Line card DP RAM. 


2 bytes 


QUEUE 1 GET PTR. The address of the pomtcr used for 
reading from queue 1 of the Line card DP RAM. 


2 bytes 


QUEUE 1 START ADDRESS. The address of the start of 
queue 1 of the Line card DP RAM, 


2 byies 


QUEUE 1 LENGTH. The number of bytes in queue 1 of 
DP RAM. 


4 byics 






QUEUE N PUT PTR. The address of the pointer used for 
writing to queue 1 of the Line card DP RAM. 


2 bytes 


QUEUE N GET PTR. The address of the pointer used for 
reading from queue 1 of the Line card DP RAM. 


2 bytes 


QUEUE N START ADDRESS. The address of the start of 
queue 1 of the Line card DP RAM. 


2 bytes 


QUEUE N LENGTH. The number of bytes in queue 1 of 
DP RAM. 


4 bytes 
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